Two bugs: we couldn't report the serial number correctly if it was long
enough, and it wasn't possible to connect to a device whose serial number
was long enough to overflow a different fixed-length buffer.
Bug: http://b/20317730
Change-Id: Ic9cf3c847066449ac78069bd1718184935098ac7
Don't double mount /dev and its subdirectories anymore. Instead, the
first stage init is solely responsible for mounting it.
Don't have init prepare the property space. This is the responsibility
of the second stage init.
Don't have SELinux use the property space to determine how we should
be running. Instead, create a new function and extract the data we
need directly from /proc/cmdline. SELinux needs this information in
the first stage init process where the property service isn't available.
Change-Id: I5b4f3bec79463a7381a68f30bdda78b5cc122a96
SELinux provides it's own /dev/null character device at
/sys/fs/selinux/null. This character device is exactly the same
as /dev/null, including the same major/minor numbers, and can
be used wherever /dev/null is used.
Use /sys/fs/selinux/null instead of trying to create our own
/dev/__null__ device. This moves us one step closer to eliminating
all uses of mknod() by init.
/sys/fs/selinux/null is only available once the /sys/fs/selinux filesystem
is mounted. It's not available to the first stage init, so we
still have to fall back to mknod then.
Change-Id: Ic733767ea6220a130537de33cc478ae79578ce20
The first stage init mounts /proc and /sys, and then the second
stage init also mounts /proc and /sys on top of the existing mount.
Only mount these two directories once, in the first stage init.
Not yet fixed: the double mounting of /dev. Removing the double
mounting doesn't work right now because both init stages are trying
to create a property space, and if the double mount of /dev goes away,
the property service in the second stage init fails to work.
Change-Id: I13719027a47526d074390c2b1a605ad99fb43a8f
write_file() returned -errno on error, not -1. Callers who check for
-1 would falsely believe that the write was successful when it wasn't.
Fixup write_file so that it return -1 on error consistent
with other functions.
Change-Id: Ic51aaf8678d8d97b2606bd171f11b3b11f642e39
None of our tools -- except for top, which I'd fixed previously --
handles SIGPIE correctly. Let's just handle SIGPIPE in the driver.
Bug: https://code.google.com/p/android/issues/detail?id=157920
Change-Id: I322ea411f53c71585a64118c217d54389f675d4e
Not just because it's what the cool kids are doing --- it also lets us
simplify the inner loop and decouple it from whatever systems want to
be woken to perform some activity if there's data to be read on some fd.
Currently this is just used to clean up the existing signal handling,
keychord, and property service code.
Change-Id: I4d7541a2c4386957ad877df69e3be08b96a7dec5
All the code that was being delayed does is create a socket. We can
do that straight away, avoid the overhead, and simplify our main loop.
The keychord fd, on the other hand, seems a little tricky. It looks
like /dev/keychord isn't immediately available, at least not on N9;
we have to wait for ueventd to set us up the bomb.
Change-Id: I020e75b8e4b233497707f0a3cbbb6038b714161f
We can set it up earlier, and error reporting like this helped me find
the SELinux problem with the last change to this code.
Change-Id: If0f38bc5ff0465c4030e2d39d34f31f49b2d8487
This reverts commit b862bd00a4.
This change was fine but an earlier change it depended on was broken.
That change has been fixed and resubmitted.
Bug: http://b/19702273
Change-Id: I17e565721026e48e2a73526f729f2481d4d6edb5
This reverts commit 4217374611.
It turns out that the kernel passes any unrecognized arguments on to init,
and (at least) N6 and N9 have such arguments. My lazy check of argc was
thus insufficient to recognize what stage of init we were in, so we'd
skip to stage 2 and not set up SELinux. And apparently you can get a
very long way with SELinux off... We'll fix that in a later change.
Bug: 19702273
Change-Id: I43b3fb722fed35dd217cb529cbcac9a29aff4e4b
- On a N9 64-bit benchmark, the __android_log_is_loggable overhead
is roughly 500ns (1/2 of a syscall?)
Bug: 19544788
Bug: 17760225
Bug: 20416721
Change-Id: Ib9e4d06d96e1b19ca5d459e569ead451ef47a9c0
The umount2 call was using the magic constant 2 which is
has a defined and proper macro in mount.h as MNT_DETATCH.
Change-Id: I4ca4a6d31cbf5495c545088e3d90a8894a9f912f
