On 13 January 2015 at 16:35, Martin Pitt <martin.pitt@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-container@persis.sys.usb.config=*.target
>> - start android-container@persist.sys.usb.config=mtp.target [*]
>
> That's the mtp-server package's job, right?
>
No. the bridge will start the
"android-container@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-container@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
