The Service Manager relies on its ability to control service process lifetime directly in order to have authoritative knowledge of exactly what service(s) is/are being hosted in any given (child) process.

In practice - if we want to avoid having Two Ways of Doing Things from a client's perspective - we'll also need already-running or long-running system processes to be able to expose themselves to the Service Manager as services which clients can reliably reach using the same APIs (e.g. Connector) used to connect to "real" services.

A prerequisite is that Service Manager must be able to establish *some* kind of secure communication channel to such processes through another trusted component on the system.

As a strawman proposal for how it might work on Chrome OS:

1. A service manifest for the (Service Manager) service includes metadata
   identifying a
   (D-Bus) service name / object where the service can be located
2. Service Manager uses D-Bus to send a socket handle over to the service
   process
3. The socket is used to bootstrap Mojo
4. The Service Manager and system service both treat the primordial
   Mojo message pipe as a mojom::Service pipe
5. Service life-cycle proceeds normally

Similar behavior can be implemented on other platforms via whatever service location and connection mechanisms are provided by the OS.

This of course can all be stuffed in a client library behind a trivial API so system services can essentially just add something to main() like:

  BeAServiceManagerService(/* some metadata */, /* some Service impl */);

and then go about their merry business doing whatever else they normally do.

Note that on Chrome OS all of this is moot if we make Service Manager *the* service manager on the system, i.e. we replace Upstart with it completely, but that is not strictly necessary to build a nice system architecture, it doesn't buy us that much this early, and I think we should just punt on it.
 

The Service Manager relies on its ability to control service process lifetime directly in order to have authoritative knowledge of exactly what service(s) is/are being hosted in any given (child) process.

In practice - if we want to avoid having Two Ways of Doing Things from a client's perspective - we'll also need already-running or long-running system processes to be able to expose themselves to the Service Manager as services which clients can reliably reach using the same APIs (e.g. Connector) used to connect to "real" services.

A prerequisite is that Service Manager must be able to establish *some* kind of secure communication channel to such processes through another trusted component on the system.

As a strawman proposal for how it might work on Chrome OS:

1. A service manifest for the (Service Manager) service includes metadata
   identifying a D-Bus) service name / object where the service can be located
2. Service Manager uses D-Bus to send a socket handle over to the service
   process
3. The socket is used to bootstrap Mojo
4. The Service Manager and system service both treat the primordial
   Mojo message pipe as a mojom::Service pipe
5. Service life-cycle proceeds normally

Similar behavior can be implemented on other platforms via whatever service location and connection mechanisms are provided by the OS.

This of course can all be stuffed in a client library behind a trivial API so system services can essentially just add something to main() like:

  BeAServiceManagerService(/* some metadata */, /* some Service impl */);

and then go about their merry business doing whatever else they normally do.

Note that on Chrome OS all of this is moot if we make Service Manager *the* service manager on the system, i.e. we replace Upstart with it completely, but that is not strictly necessary to build a nice system architecture, it doesn't buy us that much this early, and I think we should just punt on it.
 

The Service Manager relies on its ability to control service process lifetime directly in order to have authoritative knowledge of exactly what service(s) is/are being hosted in any given (child) process.

In practice - if we want to avoid having Two Ways of Doing Things from a client's perspective - we'll also need already-running or long-running system processes to be able to expose themselves to the Service Manager as services which clients can reliably reach using the same APIs (e.g. Connector) used to connect to "real" services.

A prerequisite is that Service Manager must be able to establish *some* kind of secure communication channel to such processes through another trusted component on the system.

As a strawman proposal for how it might work on Chrome OS:

1. A service manifest for the (Service Manager) service includes metadata
   identifying a (D-Bus) service name / object where the service can be located
2. Service Manager uses D-Bus to send a socket handle over to the service
   process
3. The socket is used to bootstrap Mojo
4. The Service Manager and system service both treat the primordial
   Mojo message pipe as a mojom::Service pipe
5. Service life-cycle proceeds normally

Similar behavior can be implemented on other platforms via whatever service location and connection mechanisms are provided by the OS.

This of course can all be stuffed in a client library behind a trivial API so system services can essentially just add something to main() like:

  BeAServiceManagerService(/* some metadata */, /* some Service impl */);

and then go about their merry business doing whatever else they normally do.

Note that on Chrome OS all of this is moot if we make Service Manager *the* service manager on the system, i.e. we replace Upstart with it completely, but that is not strictly necessary to build a nice system architecture, it doesn't buy us that much this early, and I think we should just punt on it.