Previously init_parser.cpp was made generic and capable of parsing any
number of differently named 'sections' or prefixed lines. We now use
these capabilities to do the parsing for ueventd.
Bug: 36250207
Bug: 33785894
Test: boot bullhead and ensure the right /dev nodes exist
with the right permissions set
Test: verify no boot time difference
Change-Id: I698ca962d414f8135af32f6c9cd778841b2b8b53
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
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
Remove includes of "log.h" that really want <android-base/logging.h>
Fix header include order
Remove headers included in .cpp files that their associated .h already includes
Remove some unused headers
Test: boot bullhead
Change-Id: I2b415adfe86a5c8bbe4fb1ebc53c7b0ee2253824
Fix two formatting issues in Action::DumpState(),
Old:
on ro.crypto.state=encrypted ro.crypto.type=file zygote-start
New:
on ro.crypto.state=encrypted && ro.crypto.type=file && zygote-start
Old:
on boot
%sifup lo
%shostname localhost
%sdomainname localdomain
%swrite /proc/sys/vm/overcommit_memory 1
New:
on boot
ifup lo
hostname localhost
domainname localdomain
write /proc/sys/vm/overcommit_memory 1
Also, now that we're importing many small rc files, it no longer makes
sense to call Parser::DumpState() after each import. Therefore, move
the conditional to call Parser::DumpState() to after /init.rc and its
imports are parsed and after the late imports are parsed.
Test: Boot bullhead with DumpState() enabled and check the output
Change-Id: I0b81305b8938aa1a7133d7dd2055f34f47609cf9
ExecuteCommand may change command_ vector which leads undefined behavior
This bug is found when adding logs in ExecuteCommand printing our Command class fields
Bug: 32838381
Test: on emulator
Change-Id: I96468bd2192ca80013871a3a6ac4132149363fff
Remove the /dev/__kmsg__ workarounds (which can then be removed
from sepolicy), and fix confusion in the translation between
android-base logging and kernel logging priorities (in particular,
where 'notice' comes in the hierarchy).
Bug: http://b/30317429
Change-Id: I6eaf9919904b6b55bc402c20bf1a4ae269014bc7
Test: adb shell dmesg | grep init
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
Tom Cherry
Elliott Hughes
Wei Wang
Treehugger Robot
Nick Desaulniers
Chih-Hung Hsieh