Tuesday, 13 January 2015

Re: upstart-local-bridge plan to support systemd

Le 12/01/2015 20:39, Dimitri John Ledkov a écrit :
> 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 [email protected]=*.target
> - start [email protected]=mtp.target [*]
>
> A job that should only be executed when such a property has value mtp
> will declare:
> [Unit]
> [email protected]=mtp.target
> [Install]
> [email protected]=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
> [email protected]\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.
>

Makes a lot of sense. I have some ideas for the systemd session part,
but let's discuss that later on as its not a topic for vivid.
(Note as well that we don't use preset yet, there is a long upstream
discussion about that and what Debian/Ubuntu should do)

Thanks for looking at that!
Didier


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel