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:
> persist.sys.usb.config=mtp on the local bridge will
> - stop all email@example.com=*.target
> - start firstname.lastname@example.org=mtp.target [*]
> 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
> email@example.com\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
> 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!
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel