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: e.g. persist.sys.usb.config=mtp on the local bridge will - stop all android-contai...@persis.sys.usb.config=*.target - start android-contai...@persist.sys.usb.config=mtp.target [*] A job that should only be executed when such a property has value mtp will declare: [Unit] BindsTo=android-contai...@persist.sys.usb.config=mtp.target [Install] WantedBy=android-contai...@persist.sys.usb.config=mtp.target 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-contai...@persist.sys.usb.config\x3mtp.target 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 starting/stopping. 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. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel