[RFC] Improving hardware access for snaps

Dustin Kirkland kirkland at canonical.com
Sat Jan 31 15:38:36 UTC 2015


Surely it will support globbing a la /dev/ttyUSB* right?
On Jan 31, 2015 5:33 PM, "Gustavo Niemeyer" <gustavo.niemeyer at canonical.com>
wrote:

> What happens if the device moves? For example, a ttyUSB0 can become
> ttyUSB1 if one unplugs and plugs it back while the system was still working
> on the original device for whatever reason.
>
>
> On Sat Jan 31 2015 at 11:52:20 AM Jamie Strandboge <jamie at canonical.com>
> wrote:
>
>> On 01/30/2015 04:42 PM, Sergio Schvezov wrote:
>> > On viernes 30 de enero de 2015 19h'31:44 ART, Jamie Strandboge wrote:
>> >> On 01/30/2015 04:18 PM, Jamie Strandboge wrote:
>> >>
>> >> ...
>> >>
>> >>> = UX =
>> >>> Relevant packaging yaml:
>> >>> name: foo
>> >>> version: 0.1
>> >>> ...
>> >>  ...
>> >>
>> >> Hmm, one thing that occurred to me is that while we want to give the
>> > device
>> >> access to a particular service/cli binary, I don't think users have a
>> way to see
>> >> what services/cli binaries a snap provides, do they? In other words:
>> >>
>> >> $ snappy install foo
>> >> ...
>> >> $ snappy add-hw foo.bar /dev/ttyS0
>> >>
>> >>
>> >> How does the user know to specify 'foo.bar'? Does the new snappy cli
>> UX cover
>> >> this anywhere? If not, we'll can leave the original proposal, but
>> prompt when
>> >> the user specifies only the package name and when there is more than
>> one
>> >> service/cli binary to choose from (like in the above yaml example). Eg:
>> >>
>> >> $ snappy install foo
>> >> ...
>> >>
>> >> $ snappy add-hw foo /dev/ttyS0             <=== only package name
>> > specified
>> >> Add access to '/dev/ttyS0' for which of the following:
>> >> [1] foo.bar
>> >> [2] foo.baz
>> >> [3] all of the above
>> >>
>> >>> 1
>> >> 'foo.bar' is now allowed to access /dev/ttyS0
>> >
>> > It should be foo_bar though, foo.bar would be akin to
>> camlistore.sergiusens or
>> > pastebinit.mvo (full package names).
>>
>> It's funny because I initially had '_' because it works better with the
>> APP_ID
>> concept and therefore the security policy. I picked '.' for consistency
>> with the
>> cli binaries, but forgot that those will use '/' in the future, so I
>> think I
>> picked the worst one.
>>
>> Choices:
>> 1. foo.bar
>> $ snappy add-hw foo.bar /dev/ttyS0
>>
>>
>> 2. foo_bar
>> $ snappy add-hw foo_bar /dev/ttyS0
>>
>>
>> 3. foo/bar
>> $ snappy add-hw foo/bar /dev/ttyS0
>>
>>
>> I think I slightly prefer '3' visually, but would be happy with '2' for
>> the
>> reasons stated above. I don't like '1' because it is inconsistent with the
>> future experience and is the most confusing.
>>
>>
>> --
>> Jamie Strandboge                 http://www.ubuntu.com/
>>
>> --
>> snappy-devel mailing list
>> snappy-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/snappy-devel
>>
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150131/73281884/attachment.html>


More information about the snappy-devel mailing list