Commit graph

11 commits

Author SHA1 Message Date
Mark Salyzyn
9f1cf25332 switch to using android-base/file.h instead of android-base/test_utils.h
Test: compile
Bug: 119313545
Change-Id: I4f7ad84743e974b4b4d1d7256088f6c8b749a237
2018-11-14 09:35:34 -08:00
Tom Cherry
7fd3bc27ec Move ActionManager to its own file
Bug: 36970783
Test: build
Change-Id: I08fa39052236b462249f79de1d02bf02bdbf4c84
2018-02-14 16:37:09 -08:00
Tom Cherry
0f6417f232 Move ActionParser to its own file
Bug: 36970783
Test: build
Change-Id: Idd5b923e4789760bb9ef67c10982b2642bc6a31a
2018-02-13 15:26:14 -08:00
Steven Moreland
6f5333a4a9 Allow a service to override another.
For instance, on vendor.img:
service foo /vendor/bin/nfc
    ...

And then on odm.img:
service foo /odm/bin/super-nfc
    override

Allows a service on ODM to override a HAL on vendor.

Bug: 69050941
Test: boot, init_tests
Change-Id: I4e908fb66e89fc6e021799fe1fa6603d3072d62a
2017-11-15 10:39:29 -08:00
Tom Cherry
cb0f9bbc85 init: run vendor commands in a separate SELinux context
One of the major aspects of treble is the compartmentalization of system
and vendor components, however init leaves a huge gap here, as vendor
init scripts run in the same context as system init scripts and thus can
access and modify the same properties, files, etc as the system can.

This change is meant to close that gap.  It forks a separate 'subcontext'
init that runs in a different SELinux context with permissions that match
what vendors should have access to.  Commands get sent over a socket to
this 'subcontext' init that then runs them in this SELinux context and
returns the result.

Note that not all commands run in the subcontext; some commands such as
those dealing with services only make sense in the context of the main
init process.

Bug: 62875318
Test: init unit tests, boot bullhead, boot sailfish

Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-29 13:06:26 -07:00
Tom Cherry
557946e57c init: use Result<T> for builtin functions
We currently throw out the return values from builtin functions and
occasionally log errors with no supporting context.  This change uses
the newly introduced Result<T> class to communicate a successful result
or an error back to callers in order to print an error with clear
context when a builtin fails.

Example:

init: Command 'write /sys/class/leds/vibrator/trigger transient' action=init (/init.rc:245) took 0ms and failed: Unable to write to file '/sys/class/leds/vibrator/trigger': open() failed: No such file or directory

Test: boot bullhead
Merged-In: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
Change-Id: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
2017-08-14 14:07:39 -07:00
Tom Cherry
11a3aeeae3 init: introduce Result<T> for return values and error handling
init tries to propagate error information up to build context before
logging errors.  This is a good thing, however too often init has the
overly verbose paradigm for error handling, below:

bool CalculateResult(const T& input, U* output, std::string* err)

bool CalculateAndUseResult(const T& input, std::string* err) {
  U output;
  std::string calculate_result_err;
  if (!CalculateResult(input, &output, &calculate_result_err)) {
    *err = "CalculateResult " + input + " failed: " +
      calculate_result_err;
      return false;
  }
  UseResult(output);
  return true;
}

Even more common are functions that return only true/false but also
require passing a std::string* err in order to see the error message.

This change introduces a Result<T> that is use to either hold a
successful return value of type T or to hold an error message as a
std::string.  If the functional only returns success or a failure with
an error message, Result<Success> may be used.  The classes Error and
ErrnoError are used to indicate a failed Result<T>.

A successful Result<T> is constructed implicitly from any type that
can be implicitly converted to T or from the constructor arguments for
T.  This allows you to return a type T directly from a function that
returns Result<T>.

Error and ErrnoError are used to construct a Result<T> has
failed. Each of these classes take an ostream as an input and are
implicitly cast to a Result<T> containing that failure.  ErrnoError()
additionally appends ": " + strerror(errno) to the end of  the failure
string to aid in interacting with C APIs.

The end result is that the above code snippet is turned into the much
clearer example below:

Result<U> CalculateResult(const T& input);

Result<Success> CalculateAndUseResult(const T& input) {
  auto output = CalculateResult(input);
  if (!output) {
    return Error() << "CalculateResult " << input << " failed: "
                   << output.error();
  }
  UseResult(*output);
  return Success();
}

This change also makes this conversion for some of the util.cpp
functions that used the old paradigm.

Test: boot bullhead, init unit tests
Merged-In: I1e7d3a8820a79362245041251057fbeed2f7979b
Change-Id: I1e7d3a8820a79362245041251057fbeed2f7979b
2017-08-14 14:07:30 -07:00
Tom Cherry
67dee626e0 init: remove Parser singleton and related cleanup
* Remove the Parser singleton (Hooray!)
* Rename parser.* to tokenizer.* as this is actually a tokenizer
* Rename init_parser.* to parser.* as this is a generic parser
* Move contents of init_parser_test.cpp to service_test.cpp as this
  actually is a test of the parsing in MakeExecOneshotService() and
  nothing related to (init_)parser.cpp

Test: boot bullhead
Test: bool sailfish
Test: init unit tests
Change-Id: I4fe39e6483f58ebd3ce5ee715a45dbba0acf5d91
2017-07-27 13:23:32 -07:00
Tom Cherry
81f5d3ebef init: create android::init:: namespace
With some small fixups along the way

Test: Boot bullhead
Test: init unit tests
Change-Id: I7beaa473cfa9397f845f810557d1631b4a462d6a
2017-06-23 13:21:20 -07:00
Tom Cherry
2cbbe9f7a3 init: do not log directly from read_file() and write_file()
Their callers may be able to add more context, so use an error string
to record the error.

Bug: 38038887
Test: boot bullhead
Test: Init unit tests
Change-Id: I46690d1c66e00a4b15cadc6fd0d6b50e990388c3
2017-05-05 14:37:12 -07:00
Tom Cherry
ad54d094cd 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-21 18:27:42 -07:00