ParseLineSection() provides 'args' as an rvalue reference, so its
callers can and should use it as such. This saves some copying
overhead and cleans up the code a bit.
Test: boot
Change-Id: Ib906318583dc81de9ea585f5f09fdff35403be1b
Allow it to fail. When there is an error for a section ending,
print the error pointing to the line where the section starts.
Bug: 69050941
Test: boot, init_tests
Change-Id: I1d8ed25f4b74cc9ac24d38b8075751c7d606aea8
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
* Remove the Parser singleton (Hooray!)
* Rename parser.* to tokenizer.* as this is actually a tokenizer
* Rename init_parser.* to parser.* as this is a generic parser
* Move contents of init_parser_test.cpp to service_test.cpp as this
actually is a test of the parsing in MakeExecOneshotService() and
nothing related to (init_)parser.cpp
Test: boot bullhead
Test: bool sailfish
Test: init unit tests
Change-Id: I4fe39e6483f58ebd3ce5ee715a45dbba0acf5d91
We have been seeing panics and errors during shutdown sequence in
some vendor's platform, and it is required to disable error handling
during shutdown.
This CL separates the shutdown request to execute another "shutdown"
trigger at the beginning of shutdown stage. And vendor can use this
trigger to add custom commands needed for shutting down gracefully.
Bug: 38203024
Bug: 62084631
Test: device reboot/shutdown
Change-Id: I3fac4ed59f06667d86e477ee55ed391cf113717f
The term 'trigger' should be used in 'Action' to indicate what causes
the 'Action' to be executed.
The term 'event' should be used in ActionManager's queue to indicate
a state change that is checked against the 'triggers' of an 'Action' to
see if it should execute.
Convert the previous Trigger class to std::variant, as the latter is
better suited for this use.
Change-Id: I2558367c8318b536aa69fcec93793f1c12857ef5
Start a init_tests.cpp file for end-to-end tests that parse small init script
segments and verify that they act as expected.
The first tests ensure that the execution order of event triggers
happens appropriately.
Test: Boot bullhead, run unit tests
Change-Id: Ic446c02605ab796fd41e0596ce1fd381aee80ce0
Remove the dependency on Action and Service from what should be a
generic Parser class.
Make ActionParser, ImportParser, and ServiceParser take a pointer to
their associated classes instead of accessing them through a
singleton.
Misc fixes to SectionParser Interface:
1) Make SectionParser::ParseLineSection() non-const as it always should
have been.
2) Use Rvalue references where appropriate
3) Remove extra std::string& filename in SectionParser::EndFile()
4) Only have SectionParser::ParseSection() as pure virtual
Document SectionParser.
Make ImportParser report the filename and line number of failed imports.
Make ServiceParser report the filename and line number of duplicated services.
Test: Boot bullhead
Change-Id: I86568a5b375fb4f27f4cb235ed1e37635f01d630
In the past, I had thought it didn't make sense to have multiple
Action classes with identical triggers within ActionManager::actions_,
and opted to instead combine these into a single action. In theory,
it should reduce memory overhead as only one copy of the triggers
needs to be stored.
In practice, this ends up not being a good idea.
Most importantly, given a file with the below three sections in this
same order:
on boot
setprop a b
on boot && property:true=true
setprop c d
on boot
setprop e f
Assuming that property 'true' == 'true', when the `boot` event
happens, the order of the setprop commands will actually be:
setprop a b
setprop e f
setprop c d
instead of the more intuitive order of:
setprop a b
setprop c d
setprop e f
This is a mistake and this CL fixes it. It also documents this order.
Secondly, with a given 'Action' now spanning multiple files, in order
to keep track of which file a command is run from, the 'Command'
itself needs to store this. Ironically to the original intention,
this increases total ram usage. This change now only stores the file
name in each 'Action' instead of each 'Command'. All in all this is a
negligible trade off of ram usage.
Thirdly, this requires a bunch of extra code and assumptions that
don't help anything else. In particular it forces to keep property triggers
sorted for easy comparison, which I'm using an std::map for currently,
but that is not the best data structure to contain them.
Lastly, I added the filename and line number to the 'processing
action' LOG(INFO) message.
Test: Boot bullhead, observe above changes
Test: Boot sailfish, observe no change in boot time
Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
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
When init queues a trigger, it actually enqueues all of the Actions
that match with that given trigger. This works currently because
all init scripts are loaded and therefore all Actions are available
before init starts queueing any triggers.
To support loading init scripts after init has started queueing
triggers, this change enqueues Trigger objects instead of their
matching Actions. Each Trigger object then matches its associated
Actions during its execution.
Additionally, this makes a few cosmetic clean ups related to triggers.
Bug: 23186545
Change-Id: I5d177458e6df1c4b32b1072cf77e87ef952c87e4
This creates the concept of 'event_trigger' vs 'property_trigger'
Previously these were merged into one, such that 'on property:a=b &&
property:b=c' is triggered when properties a=b and b=c as expected,
however combinations such as 'on early-boot && boot' would trigger
during both early-boot and boot. Similarly, 'on early-boot &&
property:a=b' would trigger on both early-boot and again when property
a equals b.
The event trigger distinction ensures that the first example fails to
parse and the second example only triggers on early-boot if
property a equals b.
This coalesces Actions with the same triggers into a single Action object
Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
