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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "action.h"
|
|
|
|
|
2017-04-07 01:30:22 +02:00
|
|
|
#include <android-base/logging.h>
|
2017-03-29 01:40:41 +02:00
|
|
|
#include <android-base/properties.h>
|
2015-12-05 07:00:26 +01:00
|
|
|
#include <android-base/stringprintf.h>
|
2017-03-29 01:40:41 +02:00
|
|
|
#include <android-base/strings.h>
|
2015-07-24 02:53:11 +02:00
|
|
|
|
|
|
|
#include "util.h"
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
using android::base::Join;
|
|
|
|
using android::base::StringPrintf;
|
2015-07-24 02:53:11 +02:00
|
|
|
|
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) {}
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
int Command::InvokeFunc() const {
|
2015-07-30 22:52:55 +02:00
|
|
|
std::vector<std::string> expanded_args;
|
|
|
|
expanded_args.resize(args_.size());
|
|
|
|
expanded_args[0] = args_[0];
|
2015-07-24 02:53:11 +02:00
|
|
|
for (std::size_t i = 1; i < args_.size(); ++i) {
|
2015-08-26 20:43:36 +02:00
|
|
|
if (!expand_props(args_[i], &expanded_args[i])) {
|
2016-06-25 00:12:21 +02:00
|
|
|
LOG(ERROR) << args_[0] << ": cannot expand '" << args_[i] << "'";
|
2015-07-24 02:53:11 +02:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-30 22:52:55 +02:00
|
|
|
return func_(expanded_args);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
std::string Command::BuildCommandString() const {
|
|
|
|
return Join(args_, ' ');
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
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) {}
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
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) {
|
2015-08-26 20:43:36 +02:00
|
|
|
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);
|
2015-08-26 20:43:36 +02:00
|
|
|
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);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
std::size_t Action::NumCommands() const {
|
2015-07-24 02:53:11 +02:00
|
|
|
return commands_.size();
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void Action::ExecuteOneCommand(std::size_t command) const {
|
2016-11-16 21:08:30 +01:00
|
|
|
// 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);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void Action::ExecuteAllCommands() const {
|
2015-07-24 02:53:11 +02:00
|
|
|
for (const auto& c : commands_) {
|
2015-08-26 20:43:36 +02:00
|
|
|
ExecuteCommand(c);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void Action::ExecuteCommand(const Command& command) const {
|
2015-07-24 02:53:11 +02:00
|
|
|
Timer t;
|
|
|
|
int result = command.InvokeFunc();
|
|
|
|
|
2016-11-29 20:20:58 +01:00
|
|
|
double duration_ms = t.duration_s() * 1000;
|
2016-11-16 08:58:55 +01:00
|
|
|
// Any action longer than 50ms will be warned to user as slow operation
|
|
|
|
if (duration_ms > 50.0 ||
|
|
|
|
android::base::GetMinimumLogSeverity() <= android::base::DEBUG) {
|
2015-07-24 02:53:11 +02:00
|
|
|
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());
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2016-06-25 00:12:21 +02:00
|
|
|
LOG(INFO) << "Command '" << cmd_str << "' action=" << trigger_name << source
|
2016-11-16 08:58:55 +01:00
|
|
|
<< " returned " << result << " took " << duration_ms << "ms.";
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool Action::ParsePropertyTrigger(const std::string& trigger, std::string* err) {
|
2015-07-24 02:53:11 +02:00
|
|
|
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);
|
|
|
|
|
2017-03-13 19:58:58 +01:00
|
|
|
if (auto [it, inserted] = property_triggers_.emplace(prop_name, prop_value); !inserted) {
|
2015-07-24 02:53:11 +02:00
|
|
|
*err = "multiple property triggers found for same property";
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool Action::InitTriggers(const std::vector<std::string>& args, std::string* err) {
|
2015-07-24 02:53:11 +02:00
|
|
|
const static std::string prop_str("property:");
|
|
|
|
for (std::size_t i = 0; i < args.size(); ++i) {
|
2016-11-17 04:19:49 +01:00
|
|
|
if (args[i].empty()) {
|
|
|
|
*err = "empty trigger is not valid";
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-07-24 02:53:11 +02:00
|
|
|
if (i % 2) {
|
2015-08-11 21:34:22 +02:00
|
|
|
if (args[i] != "&&") {
|
2015-07-24 02:53:11 +02:00
|
|
|
*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;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool Action::InitSingleTrigger(const std::string& trigger) {
|
2015-07-24 02:53:11 +02:00
|
|
|
std::vector<std::string> name_vector{trigger};
|
|
|
|
std::string err;
|
2016-11-17 04:19:49 +01:00
|
|
|
bool ret = InitTriggers(name_vector, &err);
|
|
|
|
if (!ret) {
|
|
|
|
LOG(ERROR) << "InitSingleTrigger failed due to: " << err;
|
|
|
|
}
|
|
|
|
return ret;
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
// 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.
|
2015-07-24 02:53:11 +02:00
|
|
|
bool Action::CheckPropertyTriggers(const std::string& name,
|
2015-08-26 20:43:36 +02:00
|
|
|
const std::string& value) const {
|
2015-07-24 02:53:11 +02:00
|
|
|
if (property_triggers_.empty()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool found = name.empty();
|
2017-03-13 19:58:58 +01:00
|
|
|
for (const auto& [trigger_name, trigger_value] : property_triggers_) {
|
2015-08-11 21:34:22 +02:00
|
|
|
if (trigger_name == name) {
|
|
|
|
if (trigger_value != "*" && trigger_value != value) {
|
2015-07-24 02:53:11 +02:00
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
found = true;
|
|
|
|
}
|
|
|
|
} else {
|
2017-03-29 01:40:41 +02:00
|
|
|
std::string prop_val = android::base::GetProperty(trigger_name, "");
|
|
|
|
if (prop_val.empty() || (trigger_value != "*" && trigger_value != prop_val)) {
|
2015-07-24 02:53:11 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool Action::CheckEventTrigger(const std::string& trigger) const {
|
2015-07-24 02:53:11 +02:00
|
|
|
return !event_trigger_.empty() &&
|
2015-08-11 21:34:22 +02:00
|
|
|
trigger == event_trigger_ &&
|
2015-07-24 02:53:11 +02:00
|
|
|
CheckPropertyTriggers();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Action::CheckPropertyTrigger(const std::string& name,
|
2015-08-26 20:43:36 +02:00
|
|
|
const std::string& value) const {
|
2015-07-24 02:53:11 +02:00
|
|
|
return event_trigger_.empty() && CheckPropertyTriggers(name, value);
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
std::string Action::BuildTriggersString() const {
|
2017-03-13 20:24:49 +01:00
|
|
|
std::vector<std::string> triggers;
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2017-03-13 19:58:58 +01:00
|
|
|
for (const auto& [trigger_name, trigger_value] : property_triggers_) {
|
2017-03-13 20:24:49 +01:00
|
|
|
triggers.emplace_back(trigger_name + '=' + trigger_value);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
if (!event_trigger_.empty()) {
|
2017-03-13 20:24:49 +01:00
|
|
|
triggers.emplace_back(event_trigger_);
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
2017-03-13 20:24:49 +01:00
|
|
|
|
|
|
|
return Join(triggers, " && ");
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void Action::DumpState() const {
|
2015-07-24 02:53:11 +02:00
|
|
|
std::string trigger_name = BuildTriggersString();
|
2016-06-25 00:12:21 +02:00
|
|
|
LOG(INFO) << "on " << trigger_name;
|
2015-07-24 02:53:11 +02:00
|
|
|
|
|
|
|
for (const auto& c : commands_) {
|
2015-08-26 20:43:36 +02:00
|
|
|
std::string cmd_str = c.BuildCommandString();
|
2017-03-13 20:24:49 +01:00
|
|
|
LOG(INFO) << " " << cmd_str;
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-11 21:34:22 +02:00
|
|
|
class EventTrigger : public Trigger {
|
|
|
|
public:
|
2016-04-30 00:44:04 +02:00
|
|
|
explicit EventTrigger(const std::string& trigger) : trigger_(trigger) {
|
2015-08-11 21:34:22 +02:00
|
|
|
}
|
2015-08-26 20:43:36 +02:00
|
|
|
bool CheckTriggers(const Action& action) const override {
|
|
|
|
return action.CheckEventTrigger(trigger_);
|
2015-08-11 21:34:22 +02:00
|
|
|
}
|
|
|
|
private:
|
2015-08-26 20:43:36 +02:00
|
|
|
const std::string trigger_;
|
2015-08-11 21:34:22 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
class PropertyTrigger : public Trigger {
|
|
|
|
public:
|
|
|
|
PropertyTrigger(const std::string& name, const std::string& value)
|
|
|
|
: name_(name), value_(value) {
|
|
|
|
}
|
2015-08-26 20:43:36 +02:00
|
|
|
bool CheckTriggers(const Action& action) const override {
|
|
|
|
return action.CheckPropertyTrigger(name_, value_);
|
2015-08-11 21:34:22 +02:00
|
|
|
}
|
|
|
|
private:
|
2015-08-26 20:43:36 +02:00
|
|
|
const std::string name_;
|
|
|
|
const std::string value_;
|
2015-08-11 21:34:22 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
class BuiltinTrigger : public Trigger {
|
|
|
|
public:
|
2016-04-30 00:44:04 +02:00
|
|
|
explicit BuiltinTrigger(Action* action) : action_(action) {
|
2015-08-11 21:34:22 +02:00
|
|
|
}
|
2015-08-26 20:43:36 +02:00
|
|
|
bool CheckTriggers(const Action& action) const override {
|
|
|
|
return action_ == &action;
|
2015-08-11 21:34:22 +02:00
|
|
|
}
|
|
|
|
private:
|
2015-08-26 20:43:36 +02:00
|
|
|
const Action* action_;
|
2015-08-11 21:34:22 +02:00
|
|
|
};
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
ActionManager::ActionManager() : current_command_(0) {
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
ActionManager& ActionManager::GetInstance() {
|
|
|
|
static ActionManager instance;
|
|
|
|
return instance;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
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));
|
2015-08-26 20:43:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueueEventTrigger(const std::string& trigger) {
|
2015-08-11 21:34:22 +02:00
|
|
|
trigger_queue_.push(std::make_unique<EventTrigger>(trigger));
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueuePropertyTrigger(const std::string& name,
|
2015-08-26 20:43:36 +02:00
|
|
|
const std::string& value) {
|
2015-08-11 21:34:22 +02:00
|
|
|
trigger_queue_.push(std::make_unique<PropertyTrigger>(name, value));
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void ActionManager::QueueAllPropertyTriggers() {
|
2015-07-24 02:53:11 +02:00
|
|
|
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);
|
2015-07-24 02:53:11 +02:00
|
|
|
std::vector<std::string> name_vector{name};
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
if (!action->InitSingleTrigger(name)) {
|
2015-07-24 02:53:11 +02:00
|
|
|
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);
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
trigger_queue_.push(std::make_unique<BuiltinTrigger>(action.get()));
|
|
|
|
actions_.emplace_back(std::move(action));
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::ExecuteOneCommand() {
|
2015-08-26 20:43:36 +02:00
|
|
|
// Loop through the trigger queue until we have an action to execute
|
2015-08-11 21:34:22 +02:00
|
|
|
while (current_executing_actions_.empty() && !trigger_queue_.empty()) {
|
2015-08-26 20:43:36 +02:00
|
|
|
for (const auto& action : actions_) {
|
|
|
|
if (trigger_queue_.front()->CheckTriggers(*action)) {
|
|
|
|
current_executing_actions_.emplace(action.get());
|
|
|
|
}
|
|
|
|
}
|
2015-08-11 21:34:22 +02:00
|
|
|
trigger_queue_.pop();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (current_executing_actions_.empty()) {
|
2015-07-24 02:53:11 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
auto action = current_executing_actions_.front();
|
2015-07-24 02:53:11 +02:00
|
|
|
|
2015-08-11 21:34:22 +02:00
|
|
|
if (current_command_ == 0) {
|
2015-07-24 02:53:11 +02:00
|
|
|
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() << ")";
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
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_;
|
2015-08-11 21:34:22 +02:00
|
|
|
if (current_command_ == action->NumCommands()) {
|
2015-08-26 20:43:36 +02:00
|
|
|
current_executing_actions_.pop();
|
2015-08-11 21:34:22 +02:00
|
|
|
current_command_ = 0;
|
2015-08-26 20:43:36 +02:00
|
|
|
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));
|
|
|
|
}
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
bool ActionManager::HasMoreCommands() const {
|
2015-08-11 21:34:22 +02:00
|
|
|
return !current_executing_actions_.empty() || !trigger_queue_.empty();
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
void ActionManager::DumpState() const {
|
|
|
|
for (const auto& a : actions_) {
|
|
|
|
a->DumpState();
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
2015-08-26 20:43:36 +02:00
|
|
|
}
|
2015-07-24 02:53:11 +02:00
|
|
|
|
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 ActionParser::ParseSection(const std::vector<std::string>& args, const std::string& filename,
|
|
|
|
int line, std::string* err) {
|
2015-08-26 20:43:36 +02:00
|
|
|
std::vector<std::string> triggers(args.begin() + 1, args.end());
|
|
|
|
if (triggers.size() < 1) {
|
|
|
|
*err = "actions must have a trigger";
|
|
|
|
return false;
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
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);
|
2015-08-26 20:43:36 +02:00
|
|
|
if (!action->InitTriggers(triggers, err)) {
|
|
|
|
return false;
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
2015-08-26 20:43:36 +02:00
|
|
|
action_ = std::move(action);
|
|
|
|
return true;
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
|
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 ActionParser::ParseLineSection(const std::vector<std::string>& args, int line,
|
|
|
|
std::string* err) {
|
|
|
|
return action_ ? action_->AddCommand(args, line, err) : false;
|
2015-08-26 20:43:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void ActionParser::EndSection() {
|
|
|
|
if (action_ && action_->NumCommands() > 0) {
|
|
|
|
ActionManager::GetInstance().AddAction(std::move(action_));
|
2015-07-24 02:53:11 +02:00
|
|
|
}
|
|
|
|
}
|