冷启动完成之前，在Early-init中启动本机服务 [英] Start native service at early-init before coldboot done

问题描述

引导顺序是通过system/core/rootdir/init.rc和其他*.rc文件定义的.这种方法允许将任何操作绑定到任何引导阶段(early-init，init等).同样在system/core/init/init.cpp中定义了以下引导顺序:
-...;
-early-init;
-wait_for_coldboot_done;
-...;
-init;
-....

Boot sequence in Android is defined via system/core/rootdir/init.rc and other *.rc files. Such approach allows to bind any action to any boot stage (early-init, init, etc). Also in system/core/init/init.cpp is defined the following sequence of the boot:
- ...;
- early-init;
- wait_for_coldboot_done;
- ...;
- init;
- ....

这意味着绑定到early-init阶段的导入*.rc文件内部的某些操作可以在coldboot(和SELinux初始化)由ueventd完成之前开始.

It means that some action inside imported *.rc file binded to the early-init stage can be started before coldboot (and SELinux initialization) will be finished by the ueventd.

所以我的问题是:如果本机服务要在coldboot完成之前启动，它是否可以正常工作(显然，这意味着该服务不需要ueventd应该创建的任何设备)?

So my question: does a native service work correctly if it will be started before coldboot done (obviously it means that such service does not require any device which should be created by the ueventd)?

推荐答案

所以我的问题是:如果本机服务将在coldboot完成之前启动，则它可以正常工作吗?

So my question: does a native service work correctly if it will be started before coldboot done?

有时它可能会正常工作，但在一般情况下可能会失败.如果本机服务不与任何设备交互，则不需要/dev/文件系统.但是，绑定服务通过绑定IPC 进行通信，这需要打开绑定驱动程序(进行交互)在内核层和用户空间层之间):

Sometimes it may work correct but in general case it may fail. If native service doesn't interact with any device it doesn't require the /dev/ file system. But binderized services communicate via Binder IPC which is require opening the binder driver (for interact between kernel and userspace layers):

frameworks/native/include/binder/BinderService.h :

template<typename SERVICE>
class BinderService
{
public:
    ...
    static void instantiate() { publish(); }
    ...
    static status_t publish(bool allowIsolated = false) {
        sp<IServiceManager> sm(defaultServiceManager());
        return sm->addService(
                String16(SERVICE::getServiceName()),
                new SERVICE(), allowIsolated);
    }

frameworks/native/libs/binder/IServiceManager.cpp :

sp<IServiceManager> defaultServiceManager()
{
                ...
                ProcessState::self()->getContextObject(NULL));

frameworks/native/libs/binder/ProcessState.cpp :

sp<ProcessState> ProcessState::self()
{
    ...
    gProcess = new ProcessState("/dev/binder");
    return gProcess;
}

ProcessState::ProcessState(const char *driver)
    : mDriverName(String8(driver))
    , mDriverFD(open_driver(driver))
    ...
    {
        if (mDriverFD >= 0) {
        // mmap the binder, providing a chunk of virtual address space to receive transactions.
        mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
        if (mVMStart == MAP_FAILED) {
            // *sigh*
            ...
            ALOGE("Using /dev/binder failed: unable to mmap transaction memory.\n");
    LOG_ALWAYS_FATAL_IF(mDriverFD < 0, "Binder driver could not be opened.  Terminating.");
}

static int open_driver(const char *driver)
{
    int fd = open(driver, O_RDWR | O_CLOEXEC);
    if (fd >= 0) {
    ...
    } else {
        ALOGW("Opening '%s' failed: %s\n", driver, strerror(errno));
    }
    return fd;
}

但是Binder驱动程序/der/binder(以及/dev/hwbinder和/dev/vndbinder)是在coldboot阶段由ueventd根据ueventd.rc创建的.

But the Binder driver /der/binder (as well as /dev/hwbinder and /dev/vndbinder) is created at the coldboot stage by the ueventd according to ueventd.rc.

系统/核心/rootdir/ueventd.rc:

...
/dev/binder               0666   root       root
/dev/hwbinder             0666   root       root
/dev/vndbinder            0666   root       root
...

因此，如果在coldboot完成之前启动本机服务，它将不会打开/dev/binder！

So if a native service was be started before coldboot done it wouldn't open the /dev/binder!

也在coldboot完成之前cgrops和SELinux(不确定)未初始化:
system/core/rootdir/init.rc :

Also at before coldboot done the cgrops and SELinux (not sure) are not initialized:
system/core/rootdir/init.rc:

on init
    ...
    # Mount cgroup mount point for cpu accounting
    mount cgroup none /acct cpuacct
    mkdir /acct/uid

P.S.但是，如果服务以直通模式进行通信?

P.S. But if a service communicates in passthrough mode?

这篇关于冷启动完成之前，在Early-init中启动本机服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！