I've heard that keyword_map is too complex, in particular the tuple
and the pair in BuiltinFunctionMap, so this change removes a lot of
that complexity and, more importantly, better documents how all of
this works.
Test: boot, init unit tests
Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
X86 Kernel could pass CPU capablity to init as argument. This will cause init
can't start first-stage because unknown argument. Need remove this restriction
of arguments to start init successfully.
Fixes: 122435289
Test: Android init can start successfully
Change-Id: I1d432e25553589dd7f618e42ad238b9372dbe34f
Signed-off-by: Haoyu Tang <haoyu.tang@intel.com>
Signed-off-by: Xihua Chen <xihua.chen@intel.com>
The first split of 1st/2nd stage init went a bit overboard, since it
split these even in the case of the recovery image and system-as-root,
which don't actually need the split. This change simplifies this a
bit:
system-as-root and recovery have a single combined /system/bin/init
and a symlink from /init to it.
non-system-as-root has a separate first stage init at /init on the
first stage ramdisk and a combined /system/bin/init on system.img.
Two particular benefits from this:
1) Removal of the rsync of TARGET_RAMDISK_OUT to the recovery image
2) Decrease of overall space on the recovery image since it won't have
a statically linked first stage init
This also unified the various entry points of init to depend entirely
on the arguments passed to it, instead of the hybrid of arguments and
environment variable used previously.
Bug: 80395578
Test: boot both system-as-root and non-system-as-root
Change-Id: Ic2f29b6f56b7defc80eaa0e7cd0c9107e978816f
I'd be not doing this for a while since some of this code doesn't
compile on host and libinit previously did. But after realizing
the property_service.cpp (libinit) references symbols in init.cpp
(init) and seeing a new linker error crop up due to that, it's time to
make the fix.
My only hold out previously was that libinit compiled on host bionic
and some of init (builtins.cpp, etc) do not, however given that we
don't actually have host bionic support or host bionic init tests,
that isn't a good reason. We can and should mock out the libraries
that aren't available with host bionic when ready.
Test: build, unit tests, boot
Change-Id: Ie49362ddb637924efc272540a4f32b693643fcdc
