tequilaOS/platform_system_core
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_system_core/init/action.h

102 lines
3.2 KiB
C
Raw Normal View History

init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
/*
* Copyright (C) 2015 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef _INIT_ACTION_H
#define _INIT_ACTION_H
#include <map>
#include <queue>
#include <string>
init: rename 'Trigger' to 'Event' and convert to std::variant 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
2017-04-17 22:25:29 +02:00
#include <variant>
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
#include <vector>
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
#include "builtins.h"
#include "keyword_map.h"
init: use Result<T> for builtin functions 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
2017-08-01 22:50:23 +02:00
#include "result.h"
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
#include "subcontext.h"
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
init: create android::init:: namespace With some small fixups along the way Test: Boot bullhead Test: init unit tests Change-Id: I7beaa473cfa9397f845f810557d1631b4a462d6a
2017-06-22 21:53:17 +02:00
namespace android {
namespace init {
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
Result<Success> RunBuiltinFunction(const BuiltinFunction& function,
const std::vector<std::string>& args, const std::string& context);
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
class Command {
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
public:
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
Command(BuiltinFunction f, bool execute_in_subcontext, const std::vector<std::string>& args,
int line);
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
Result<Success> InvokeFunc(Subcontext* subcontext) const;
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
std::string BuildCommandString() const;
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
int line() const { return line_; }
private:
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
BuiltinFunction func_;
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
bool execute_in_subcontext_;
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
std::vector<std::string> args_;
int line_;
};
init: rename 'Trigger' to 'Event' and convert to std::variant 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
2017-04-17 22:25:29 +02:00
using EventTrigger = std::string;
using PropertyChange = std::pair<std::string, std::string>;
using BuiltinAction = class Action*;
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
class Action {
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
public:
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
Action(bool oneshot, Subcontext* subcontext, const std::string& filename, int line);
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
init: use Result<T> for the parsing functions Test: boot bullhead Merged-In: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113 Change-Id: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113
2017-08-03 02:01:36 +02:00
Result<Success> AddCommand(const std::vector<std::string>& args, int line);
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
void AddCommand(BuiltinFunction f, const std::vector<std::string>& args, int line);
init: use Result<T> for the parsing functions Test: boot bullhead Merged-In: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113 Change-Id: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113
2017-08-03 02:01:36 +02:00
Result<Success> InitTriggers(const std::vector<std::string>& args);
Result<Success> InitSingleTrigger(const std::string& trigger);
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
std::size_t NumCommands() const;
void ExecuteOneCommand(std::size_t command) const;
void ExecuteAllCommands() const;
init: rename 'Trigger' to 'Event' and convert to std::variant 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
2017-04-17 22:25:29 +02:00
bool CheckEvent(const EventTrigger& event_trigger) const;
bool CheckEvent(const PropertyChange& property_change) const;
bool CheckEvent(const BuiltinAction& builtin_action) const;
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
std::string BuildTriggersString() const;
void DumpState() const;
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
bool oneshot() const { return oneshot_; }
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
const std::string& filename() const { return filename_; }
int line() const { return line_; }
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
static void set_function_map(const KeywordFunctionMap* function_map) {
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
function_map_ = function_map;
}
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
private:
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
void ExecuteCommand(const Command& command) const;
bool CheckPropertyTriggers(const std::string& name = "",
const std::string& value = "") const;
init: use Result<T> for the parsing functions Test: boot bullhead Merged-In: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113 Change-Id: I7f00c5f0f54dd4fe05df73e1d6a89b56d788e113
2017-08-03 02:01:36 +02:00
Result<Success> ParsePropertyTrigger(const std::string& trigger);
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
std::map<std::string, std::string> property_triggers_;
std::string event_trigger_;
init: Use classes for parsing and clean up memory allocations 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
2015-08-26 20:43:36 +02:00
std::vector<Command> commands_;
bool oneshot_;
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
Subcontext* subcontext_;
init: Stop combining actions 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
2017-04-18 22:21:54 +02:00
std::string filename_;
int line_;
init: run vendor commands in a separate SELinux context 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
2017-09-13 00:58:47 +02:00
static const KeywordFunctionMap* function_map_;
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
};
init: create android::init:: namespace With some small fixups along the way Test: Boot bullhead Test: init unit tests Change-Id: I7beaa473cfa9397f845f810557d1631b4a462d6a
2017-06-22 21:53:17 +02:00
} // namespace init
} // namespace android
init: Create classes for Action and Command 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
2015-07-24 02:53:11 +02:00
#endif
Reference in a new issue Copy permalink