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
Certain platforms list their platform devices with a path other than
the current /devices or /devices/platform. Additionally, sometimes
these paths are a platform device themselves. An example are devices
with a path /devices/soc.0/... where /devices/soc.0 is also a platform
devices.
Instead of continuing to special case these path prefixes, we can
consider the entire path, given that no mmc or usb devices create
platform devices as subdevices, which they should not by their very
nature.
This keeps the symlinks for block devices named identically for
current platform devices and places them in /dev/block/<full path to
device> for devices in locations other than /devices or
/devices/platform, eg /dev/block/platform/soc.0/7824900.sdhci
This keeps the symlinks for character deviced named identically for
all cases.
Change-Id: Ifc8eedf1086db1826dbc8f7e96cdfcfa5da876b3
Per-UID quota has a threshold of 12.5% of the total log size.
If less than that space is taken by the UID, then we
will not engage the pruning based on worst UID.
Change-Id: I9f15c9a26938f1115eb75e9c28ddb073e7680e06
- If logd.tag.<tag> is not found, check if persist.logd.tag.<tag> is available
- Do not turn off the isLoggable functionality on "user" builds
Bug: 19544788
Bug: 17760225
Change-Id: I3fec67b547aa431438965519507033798398e1e1
Nick Kralevich