Monday, 12 January 2015

upstart-local-bridge plan to support systemd

At the moment upstart-local-bridge is used on the phone in very
specific ways. Android property watcher is run inside the
hardware-support lxc container, and it communicates property changes
to the upstart-local-bridge which makes those changes available to the
system and session inits.

The way property watcher operates will remain the same. However how
the events are exported will need to be modified slightly.

At the moment upstart-local-bridge emits a system upstart event. A few
jobs depend on those. If a user upstart session is present, it has an
upstart-event-bridge which connects to the system init and retransmits
system events to the session upstart and there are session level jobs
that react to those.

Above breaks apart if one has systemd as system/user init. Local
bridge however needs to support following consumers of the state
changes that it exposes: systemd system and upstart session.

* Systemd system:

local-bridge will generate template target, which other units can
BindsTo & WantedBy:
persist.sys.usb.config=mtp on the local bridge will
- stop all android-container@persis.sys.usb.config=*.target
- start [*]

A job that should only be executed when such a property has value mtp
will declare:

The target template will be generated at runtime in
/run/systemd/system directory.

If people are interested I can provide sample template and commands
that will generated the described behaviour on a vivid system booted
with systemd.

[*] note due to systemd-escape rules actual target name will be
android-container@persist.sys.usb.config\ but that's
mostly internal to systemd. Start/stop/status/restart etc. commands
will work with "=" name as expected.

* Upstart session:

upstart-event-bridge will be modified to fallback and connect to
local-bridge, instead of system upstart. And local-bridge will be
modified to support (mock) EventEmitted signal such that existing
events can be re-emitted on the session upstart without any other
interface changes.

* Systemd session:

Whilst currently out of scope (not yet decided on the right
implementation details), the semantics will be the same - user session
targets will be generated, started & stopped.
However I'm not sure which process should be starting/stopping
user-session level .target. E.g. local-bridge connecting and doing
that for each session systemd, or a socket published which relays
socket events and an instance of local bridge is running on the
systemd session -> connects to the relay socket and does the target

Does above sound reasonable?

This should unblock porting phone to systemd as pid 1. That is convert
remaining custom upstart jobs to systemd units, and create matching
preset policy to disable/enable things as needed.



ubuntu-devel mailing list
Modify settings or unsubscribe at: