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

130 lines
4.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 "init_parser.h"
#include "keyword_map.h"
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:
Command(BuiltinFunction f, 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
int InvokeFunc() const;
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_;
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:
explicit Action(bool oneshot, const std::string& filename, int line);
bool AddCommand(const std::vector<std::string>& args, int line, std::string* err);
void AddCommand(BuiltinFunction f, const std::vector<std::string>& args, int line);
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
bool InitTriggers(const std::vector<std::string>& args, std::string* err);
bool InitSingleTrigger(const std::string& trigger);
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: 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
static void set_function_map(const KeywordMap<BuiltinFunction>* function_map) {
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: 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
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;
bool ParsePropertyTrigger(const std::string& trigger, std::string* err);
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: 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: 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
static const KeywordMap<BuiltinFunction>* 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
};
class ActionManager {
init: create init_tests.cpp 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
2017-04-20 01:18:50 +02:00
public:
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
static ActionManager& GetInstance();
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 init_tests.cpp 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
2017-04-20 01:18:50 +02:00
// Exposed for testing
ActionManager();
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
void AddAction(std::unique_ptr<Action> 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
void QueueEventTrigger(const std::string& trigger);
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
void QueuePropertyChange(const std::string& name, const std::string& value);
void QueueAllPropertyActions();
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
void QueueBuiltinAction(BuiltinFunction func, const std::string& name);
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 ExecuteOneCommand();
bool HasMoreCommands() const;
void DumpState() const;
init: create init_tests.cpp 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
2017-04-20 01:18:50 +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
ActionManager(ActionManager const&) = delete;
void operator=(ActionManager const&) = delete;
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::unique_ptr<Action>> actions_;
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
std::queue<std::variant<EventTrigger, PropertyChange, BuiltinAction>> event_queue_;
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::queue<const Action*> current_executing_actions_;
init: Queue Triggers instead of Actions 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
2015-08-11 21:34:22 +02:00
std::size_t current_command_;
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: 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 ActionParser : public SectionParser {
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: clean up the SectionParser interface and Parser class 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
2017-04-20 00:31:58 +02:00
ActionParser(ActionManager* action_manager)
: action_manager_(action_manager), action_(nullptr) {}
bool ParseSection(std::vector<std::string>&& args, const std::string& filename, 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
std::string* err) override;
init: clean up the SectionParser interface and Parser class 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
2017-04-20 00:31:58 +02:00
bool ParseLineSection(std::vector<std::string>&& args, int line, std::string* err) override;
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
void EndSection() override;
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
private:
init: clean up the SectionParser interface and Parser class 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
2017-04-20 00:31:58 +02:00
ActionManager* action_manager_;
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::unique_ptr<Action> 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
#endif
Reference in a new issue Copy permalink