udev rules

[Jamie Strandboge]

On Mon, 2017-03-20 at 14:21 +0100, Loïc Minier wrote:
> Hi!
> 
> I saw a couple of software pieces that rely on udev rules to work; I guess
> these use cases need design to be supported in snaps; I wanted to share
> some specifics below.
> 
> 1) aksusbd is a Gemalto daemon to assert presence of a license USB dongle;
> it requires USB access, and also these udev rules that call binaries on
> addition/removal of devices and create /dev symlinks:
> http://www.feflow.info/download/FEFLOW/linux/dongle-2.41/linux_dinst/hasp.rule
> s
> 
> This is a dependency of e.g. Quortus EPC (4G core network). It could be
> delivered as a part or more likely as a separate snap since Quortus can
> operate in different modes.
> 
> 2) LimeSDR is SDR hardware that comes in USB and PCI form-factor. It might
> be used from desktop apps, e.g. Gqrx is a spectrum exploration tool and
> typically a desktop app that runs as non-root. This is the set of udev
> rules that upstream recommends installing:
> https://github.com/myriadrf/LimeSuite/blob/master/udev-rules/64-limesuite.rule
> s
> 
> These two use cases (triggering commands when devices are plugged /
> unplugged and granting permissions to desktop users to a new /dev node)
> don't seem possible right now.

That's correct.

The aksusbd case seems like it could be covered by existing interface
techniques. The providing snap slots the hasp interface and that interface could
add udev rules that point to (the snappy command aliased) /snap/bin/aksusbd.
There is probably a little thought to be had there since it assumes the aksusbd
alias and that might be somewhat awkward for different slot implementations.
This would all work for gadget snaps that provide the /dev files (like with
serial-port, etc) and won't work for classic/hotplugging.

The non-root LimeSDR case is not currently handled. To me, this is clearly
another interface (eg, 'xillybus'), but we may want to change the GROUP and not
use mode 666 if someone were going to add this interface today. What is needed
to properly handle this are device acls. This is being tracked in https://bugs.l
aunchpad.net/snappy/+bug/1646144 and additional discussion in https://bugs.launc
hpad.net/snappy/+bug/1606510/comments/14 (but I don't know the priority of this
work).

>  I think the former is probably covered in
> hotplugging requirements, not sure about the latter. Perhaps I should add
> these to some existing design doc?
> 
That seems wise for both cases (though the device acls is somewhat orthogonal).
I'm not sure where the hotplugging design doc is (iirc, Gustavo may have the
details).

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170320/f5402d64/attachment.sig>