platform_system_core/init/action.cpp

392 lines
12 KiB
C++
Raw Normal View History

/*
* 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.
*/
#include "action.h"
#include <android-base/logging.h>
#include <android-base/properties.h>
#include <android-base/stringprintf.h>
#include <android-base/strings.h>
#include "util.h"
using android::base::Join;
using android::base::StringPrintf;
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
Command::Command(BuiltinFunction f, const std::vector<std::string>& args, int line)
: func_(f), args_(args), line_(line) {}
int Command::InvokeFunc() const {
std::vector<std::string> expanded_args;
expanded_args.resize(args_.size());
expanded_args[0] = args_[0];
for (std::size_t i = 1; i < args_.size(); ++i) {
if (!expand_props(args_[i], &expanded_args[i])) {
LOG(ERROR) << args_[0] << ": cannot expand '" << args_[i] << "'";
return -EINVAL;
}
}
return func_(expanded_args);
}
std::string Command::BuildCommandString() const {
return Join(args_, ' ');
}
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
Action::Action(bool oneshot, const std::string& filename, int line)
: oneshot_(oneshot), filename_(filename), line_(line) {}
const KeywordMap<BuiltinFunction>* Action::function_map_ = nullptr;
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
bool Action::AddCommand(const std::vector<std::string>& args, int line, std::string* err) {
if (!function_map_) {
*err = "no function map available";
return false;
}
if (args.empty()) {
*err = "command needed, but not provided";
return false;
}
auto function = function_map_->FindFunction(args[0], args.size() - 1, err);
if (!function) {
return false;
}
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
AddCommand(function, args, line);
return true;
}
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 Action::AddCommand(BuiltinFunction f, const std::vector<std::string>& args, int line) {
commands_.emplace_back(f, args, line);
}
std::size_t Action::NumCommands() const {
return commands_.size();
}
void Action::ExecuteOneCommand(std::size_t command) const {
// We need a copy here since some Command execution may result in
// changing commands_ vector by importing .rc files through parser
Command cmd = commands_[command];
ExecuteCommand(cmd);
}
void Action::ExecuteAllCommands() const {
for (const auto& c : commands_) {
ExecuteCommand(c);
}
}
void Action::ExecuteCommand(const Command& command) const {
Timer t;
int result = command.InvokeFunc();
Replace the "coldboot" timeout with a property. Also rename init's existing boot-time related properties so they're all "ro.*" properties. Example result: # Three properties showing when init started... [ro.boottime.init]: [5294587604] # ...how long it waited for ueventd... [ro.boottime.init.cold_boot_wait]: [646956470] # ...and how long SELinux initialization took... [ro.boottime.init.selinux]: [45742921] # Plus one property for each service, showing when it first started. [ro.boottime.InputEventFind]: [10278767840] [ro.boottime.adbd]: [8359267180] [ro.boottime.atfwd]: [10338554773] [ro.boottime.audioserver]: [10298157478] [ro.boottime.bootanim]: [9323670089] [ro.boottime.cameraserver]: [10299402321] [ro.boottime.cnd]: [10335931856] [ro.boottime.debuggerd]: [7001352774] [ro.boottime.debuggerd64]: [7002261785] [ro.boottime.drm]: [10301082113] [ro.boottime.fingerprintd]: [10331443314] [ro.boottime.flash-nanohub-fw]: [6995265534] [ro.boottime.gatekeeperd]: [10340355242] [ro.boottime.healthd]: [7856893380] [ro.boottime.hwservicemanager]: [7856051088] [ro.boottime.imscmservice]: [10290530758] [ro.boottime.imsdatadaemon]: [10358136702] [ro.boottime.imsqmidaemon]: [10289084872] [ro.boottime.installd]: [10303296020] [ro.boottime.irsc_util]: [10279807632] [ro.boottime.keystore]: [10305034093] [ro.boottime.lmkd]: [7863506714] [ro.boottime.loc_launcher]: [10324525241] [ro.boottime.logd]: [6526221633] [ro.boottime.logd-reinit]: [7850662702] [ro.boottime.mcfg-sh]: [10337268315] [ro.boottime.media]: [10312152687] [ro.boottime.mediacodec]: [10306852530] [ro.boottime.mediadrm]: [10308707999] [ro.boottime.mediaextractor]: [10310681177] [ro.boottime.msm_irqbalance]: [7862451974] [ro.boottime.netd]: [10313523104] [ro.boottime.netmgrd]: [10285009351] [ro.boottime.oem_qmi_server]: [10293329092] [ro.boottime.per_mgr]: [7857915776] [ro.boottime.per_proxy]: [8335121605] [ro.boottime.perfd]: [10283443101] [ro.boottime.qcamerasvr]: [10329644772] [ro.boottime.qmuxd]: [10282346643] [ro.boottime.qseecomd]: [6855708593] [ro.boottime.qti]: [10286196851] [ro.boottime.ril-daemon]: [10314933677] [ro.boottime.rmt_storage]: [7859105047] [ro.boottime.servicemanager]: [7864555881] [ro.boottime.ss_ramdump]: [8337634938] [ro.boottime.ssr_setup]: [8336268324] [ro.boottime.surfaceflinger]: [7866921402] [ro.boottime.thermal-engine]: [10281249924] [ro.boottime.time_daemon]: [10322006542] [ro.boottime.ueventd]: [5618663938] [ro.boottime.vold]: [7003493920] [ro.boottime.wificond]: [10316641073] [ro.boottime.wpa_supplicant]: [18959816881] [ro.boottime.zygote]: [10295295029] [ro.boottime.zygote_secondary]: [10296637269] Bug: http://b/31800756 Test: boots Change-Id: I094cce0c1bab9406d950ca94212689dc2e15dba5
2016-11-29 20:20:58 +01:00
double duration_ms = t.duration_s() * 1000;
// Any action longer than 50ms will be warned to user as slow operation
if (duration_ms > 50.0 ||
android::base::GetMinimumLogSeverity() <= android::base::DEBUG) {
std::string trigger_name = BuildTriggersString();
std::string cmd_str = command.BuildCommandString();
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 source = StringPrintf(" (%s:%d)", filename_.c_str(), command.line());
LOG(INFO) << "Command '" << cmd_str << "' action=" << trigger_name << source
<< " returned " << result << " took " << duration_ms << "ms.";
}
}
bool Action::ParsePropertyTrigger(const std::string& trigger, std::string* err) {
const static std::string prop_str("property:");
std::string prop_name(trigger.substr(prop_str.length()));
size_t equal_pos = prop_name.find('=');
if (equal_pos == std::string::npos) {
*err = "property trigger found without matching '='";
return false;
}
std::string prop_value(prop_name.substr(equal_pos + 1));
prop_name.erase(equal_pos);
if (auto [it, inserted] = property_triggers_.emplace(prop_name, prop_value); !inserted) {
*err = "multiple property triggers found for same property";
return false;
}
return true;
}
bool Action::InitTriggers(const std::vector<std::string>& args, std::string* err) {
const static std::string prop_str("property:");
for (std::size_t i = 0; i < args.size(); ++i) {
if (args[i].empty()) {
*err = "empty trigger is not valid";
return false;
}
if (i % 2) {
if (args[i] != "&&") {
*err = "&& is the only symbol allowed to concatenate actions";
return false;
} else {
continue;
}
}
if (!args[i].compare(0, prop_str.length(), prop_str)) {
if (!ParsePropertyTrigger(args[i], err)) {
return false;
}
} else {
if (!event_trigger_.empty()) {
*err = "multiple event triggers are not allowed";
return false;
}
event_trigger_ = args[i];
}
}
return true;
}
bool Action::InitSingleTrigger(const std::string& trigger) {
std::vector<std::string> name_vector{trigger};
std::string err;
bool ret = InitTriggers(name_vector, &err);
if (!ret) {
LOG(ERROR) << "InitSingleTrigger failed due to: " << err;
}
return ret;
}
// This function checks that all property triggers are satisfied, that is
// for each (name, value) in property_triggers_, check that the current
// value of the property 'name' == value.
//
// It takes an optional (name, value) pair, which if provided must
// be present in property_triggers_; it skips the check of the current
// property value for this pair.
bool Action::CheckPropertyTriggers(const std::string& name,
const std::string& value) const {
if (property_triggers_.empty()) {
return true;
}
bool found = name.empty();
for (const auto& [trigger_name, trigger_value] : property_triggers_) {
if (trigger_name == name) {
if (trigger_value != "*" && trigger_value != value) {
return false;
} else {
found = true;
}
} else {
std::string prop_val = android::base::GetProperty(trigger_name, "");
if (prop_val.empty() || (trigger_value != "*" && trigger_value != prop_val)) {
return false;
}
}
}
return found;
}
bool Action::CheckEventTrigger(const std::string& trigger) const {
return !event_trigger_.empty() &&
trigger == event_trigger_ &&
CheckPropertyTriggers();
}
bool Action::CheckPropertyTrigger(const std::string& name,
const std::string& value) const {
return event_trigger_.empty() && CheckPropertyTriggers(name, value);
}
std::string Action::BuildTriggersString() const {
std::vector<std::string> triggers;
for (const auto& [trigger_name, trigger_value] : property_triggers_) {
triggers.emplace_back(trigger_name + '=' + trigger_value);
}
if (!event_trigger_.empty()) {
triggers.emplace_back(event_trigger_);
}
return Join(triggers, " && ");
}
void Action::DumpState() const {
std::string trigger_name = BuildTriggersString();
LOG(INFO) << "on " << trigger_name;
for (const auto& c : commands_) {
std::string cmd_str = c.BuildCommandString();
LOG(INFO) << " " << cmd_str;
}
}
class EventTrigger : public Trigger {
public:
explicit EventTrigger(const std::string& trigger) : trigger_(trigger) {
}
bool CheckTriggers(const Action& action) const override {
return action.CheckEventTrigger(trigger_);
}
private:
const std::string trigger_;
};
class PropertyTrigger : public Trigger {
public:
PropertyTrigger(const std::string& name, const std::string& value)
: name_(name), value_(value) {
}
bool CheckTriggers(const Action& action) const override {
return action.CheckPropertyTrigger(name_, value_);
}
private:
const std::string name_;
const std::string value_;
};
class BuiltinTrigger : public Trigger {
public:
explicit BuiltinTrigger(Action* action) : action_(action) {
}
bool CheckTriggers(const Action& action) const override {
return action_ == &action;
}
private:
const Action* action_;
};
ActionManager::ActionManager() : current_command_(0) {
}
ActionManager& ActionManager::GetInstance() {
static ActionManager instance;
return instance;
}
void ActionManager::AddAction(std::unique_ptr<Action> 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
actions_.emplace_back(std::move(action));
}
void ActionManager::QueueEventTrigger(const std::string& trigger) {
trigger_queue_.push(std::make_unique<EventTrigger>(trigger));
}
void ActionManager::QueuePropertyTrigger(const std::string& name,
const std::string& value) {
trigger_queue_.push(std::make_unique<PropertyTrigger>(name, value));
}
void ActionManager::QueueAllPropertyTriggers() {
QueuePropertyTrigger("", "");
}
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 ActionManager::QueueBuiltinAction(BuiltinFunction func, const std::string& name) {
auto action = std::make_unique<Action>(true, "<Builtin Action>", 0);
std::vector<std::string> name_vector{name};
if (!action->InitSingleTrigger(name)) {
return;
}
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
action->AddCommand(func, name_vector, 0);
trigger_queue_.push(std::make_unique<BuiltinTrigger>(action.get()));
actions_.emplace_back(std::move(action));
}
void ActionManager::ExecuteOneCommand() {
// Loop through the trigger queue until we have an action to execute
while (current_executing_actions_.empty() && !trigger_queue_.empty()) {
for (const auto& action : actions_) {
if (trigger_queue_.front()->CheckTriggers(*action)) {
current_executing_actions_.emplace(action.get());
}
}
trigger_queue_.pop();
}
if (current_executing_actions_.empty()) {
return;
}
auto action = current_executing_actions_.front();
if (current_command_ == 0) {
std::string trigger_name = action->BuildTriggersString();
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
LOG(INFO) << "processing action (" << trigger_name << ") from (" << action->filename()
<< ":" << action->line() << ")";
}
action->ExecuteOneCommand(current_command_);
// If this was the last command in the current action, then remove
// the action from the executing list.
// If this action was oneshot, then also remove it from actions_.
++current_command_;
if (current_command_ == action->NumCommands()) {
current_executing_actions_.pop();
current_command_ = 0;
if (action->oneshot()) {
auto eraser = [&action] (std::unique_ptr<Action>& a) {
return a.get() == action;
};
actions_.erase(std::remove_if(actions_.begin(), actions_.end(), eraser));
}
}
}
bool ActionManager::HasMoreCommands() const {
return !current_executing_actions_.empty() || !trigger_queue_.empty();
}
void ActionManager::DumpState() const {
for (const auto& a : actions_) {
a->DumpState();
}
}
bool ActionParser::ParseSection(std::vector<std::string>&& args, const std::string& filename,
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, std::string* err) {
std::vector<std::string> triggers(args.begin() + 1, args.end());
if (triggers.size() < 1) {
*err = "actions must have a trigger";
return false;
}
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
auto action = std::make_unique<Action>(false, filename, line);
if (!action->InitTriggers(triggers, err)) {
return false;
}
action_ = std::move(action);
return true;
}
bool ActionParser::ParseLineSection(std::vector<std::string>&& args, int line, std::string* err) {
return action_ ? action_->AddCommand(std::move(args), line, err) : false;
}
void ActionParser::EndSection() {
if (action_ && action_->NumCommands() > 0) {
action_manager_->AddAction(std::move(action_));
}
}