Now that Result<T> is actually expected<T, ...>, and the expected
proposal states expected<void, ...> as the way to indicate an expected
object that returns either successfully with no object or an error,
let's move init's Result<Success> to the preferred Result<void>.
Bug: 132145659
Test: boot, init unit tests
Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
One of the major aspects of treble is the compartmentalization of system
and vendor components, however init leaves a huge gap here, as vendor
init scripts run in the same context as system init scripts and thus can
access and modify the same properties, files, etc as the system can.
This change is meant to close that gap. It forks a separate 'subcontext'
init that runs in a different SELinux context with permissions that match
what vendors should have access to. Commands get sent over a socket to
this 'subcontext' init that then runs them in this SELinux context and
returns the result.
Note that not all commands run in the subcontext; some commands such as
those dealing with services only make sense in the context of the main
init process.
Bug: 62875318
Test: init unit tests, boot bullhead, boot sailfish
Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
We currently throw out the return values from builtin functions and
occasionally log errors with no supporting context. This change uses
the newly introduced Result<T> class to communicate a successful result
or an error back to callers in order to print an error with clear
context when a builtin fails.
Example:
init: Command 'write /sys/class/leds/vibrator/trigger transient' action=init (/init.rc:245) took 0ms and failed: Unable to write to file '/sys/class/leds/vibrator/trigger': open() failed: No such file or directory
Test: boot bullhead
Merged-In: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
Change-Id: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
This reduces the overhead when bootcharting is on (obviously), but also
removes the "do we need to do anything for bootcharting?" check in cases
where we're not bootcharting.
Bug: http://b/23478578
Bug: http://b/33450491
Test: rebooted with bootcharting on/off
Change-Id: Id8746b5023b17d7615679eba0bcd02aee048ef1a
Most notably, there's no longer any need to guess an end time.
Bug: http://b/23478578
Bug: http://b/33450491
Test: rebooted with bootcharting on/off
Change-Id: Icb7d6859581da5526d77dfc5aa4d57c9bfbfd7e2
Create a Parser class that uses multiple SectionParser interfaces to
handle parsing the different sections of an init rc.
Create an ActionParser and ServiceParser that implement SectionParser
and parse the sections corresponding to Action and Service
classes.
Remove the legacy keyword structure and replace it with std::map's
that map keyword -> (minimum args, maximum args, function pointer) for
Commands and Service Options.
Create an ImportParser that implements SectionParser and handles the
import 'section'.
Clean up the unsafe memory handling of the Action class by using
std::unique_ptr.
Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
bootchart uses a file on the data partition to decide if it should collect
data for bootchart, but the data partition will be mounted by the mount_all
command in the "on fs" section, and it will be only added into the action
queue when command "trigger fs" is executed, but that's after the
bootchart_init action (late_init).
This change makes bootchart_init a builtin command of init,
and make it executed as the first command of "on post-fs" section
which will be triggered after the "on fs" section.
This change also refactors the bootchart code to all be in bootchart.cpp.
Change-Id: Ia74aa34ca5b785f51fcffdd383075a549b2a99d9
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Also switch the revision parsing over to sscanf as promised. I haven't
done the hardware parsing because I don't yet know whether we actually need
to keep the space-stripping code.
Change-Id: Ic33378345cd515cb08d00c543acf44eb72673396
Ideally bootchart collects system data every BOOTCHART_POLLING_MS ms.
However, the current bootchart pacing logic would collect data every
time the main loop in init.c is executed. This results in:
1. Multiple data samples being taken consecutively or prematurely. In
many cases, these data samples have the same timestamp (in jiffies).
The off-line data processing tool would complain about dividing by
zero "interval" and bail out.
2. Because of the ineffective pacing, bootchart data collection would
terminate prematurely. The total duration of data collection is usually
much shorter than what the user specifies.
The fix is to check whether BOOTCHART_POLLING_MS ms has elapsed
before taking a new data sample. For this purpose, /proc/uptime
is used to get the time values, consistent with the precision of
bootchart timestamps.
Change-Id: I106bf91dbda01059b719df6c73b8bd1cd54a64f0
Signed-off-by: Bo (Andover) Zhang <zhang@broadcom.com>
