On 13 January 2015 at 16:35, Martin Pitt <martin.p...@ubuntu.com> wrote: > Hey Dimitri, > > Dimitri John Ledkov [2015-01-12 19:39 +0000]: >> 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 [*] > > That's the mtp-server package's job, right? >
No. the bridge will start the "android-contai...@persist.sys.usb.config=mtp.target" which is empty and does nothing. (well it starts _all_ targets received / noticed by the bridge $prefix@$name=$value.target") mpt-server package then will ship .service file which actually execs the right mtp-server with the right options, the right wantedby etc. If it wishes to be stopped/started based on the android property changes, then in addition to it's standard options it can choose to follow property changes by adding BindsTo/WantedBy=$prefix@$name=$value.target. Which in the current upstart jobs is "persis.sys.usb=mtp". These generate targets, and the fact that it's state changes are emitted by the bridge are meant to approximately simulate upstart events. The bridge will have no knowledge of the .service files, and whether they have any relationship with the templated 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 > > I haven't checked yet, but systemd represents all udev devices with a > "systemd" udev tag as a device unit (see man systemd.device and > systemctl). services can then BindsTo= this (like > systemd-rfkill@.service). > Right, interesting. I have no idea how udev interracts here. As far as I can tell these properties control how the device itself is presented to other systems over usb.... e.g. whether phone should look like mtp or flash-drive or network modem when connected to a computer. Thus it's not usb-otg connection to the phone, but rather a user choice of what the phone should behave like. > If we actually see USB devices in the Ubuntu part, and not just in the > android container, this might even cut out the middle man and get us > one step closer to not depending on Android? I haven't checked yet > whether we see the device there, though. > Can you elaborate more? I thought we use android properties to control a coherent state and choice of daemons running. Android's init starts services based on properties (hardware), and so do we on the system-init (bridge) and session-init level (UI). And android properties is something that we can access everywhere with getprop. > Aside from that, I'm sure we'll need the android properties bridge for > other cases still, so many thanks for working on this! > > Martin -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel