[RFC] Improving hardware access for snaps

[Jamie Strandboge]

On 01/31/2015 09:33 AM, Gustavo Niemeyer 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.
> 
Note, this is not the final solution, this is a step towards it to unblock
people and I purposefully didn't cover the hotplug case now.

My blog post on the subject[1] discussed this:
"immediate term
...
In essence you’ll install a snap, then run a command to give the snap access to
a particular device, then you’re done.

"short term
...
After that, we’ll build on this and explore ways to make the developer and user
experience better through integration with the OEM part and ways of interacting
with the underlying system so that the user doesn’t have to necessarily know the
device name to add, but can instead be given smart choices (this can have
tie-ins to the web interface for snappy too). We’ll want to be thinking about
hotpluggable devices as well.

Since this all builds on the concept of the immediate term solution, it also
supports our trust-model and goals fully and is relatively easy to implement."


I think a glob is sufficient for now (snappy add-hw foo/bar /dev/ttyUSB*) while
we come up with the refined solution. It is tempting for us to explore the short
term options now (and there are many ideas here) but we want to unblock people
now. I want to get the basic UX nailed down, then we'll get to things like the
OEM part, hotplugging, etc soon.

[1]https://penguindroppings.wordpress.com/2015/01/30/snappy-app-trust-model/

> 
> On Sat Jan 31 2015 at 11:52:20 AM Jamie Strandboge <jamie at canonical.com
> <mailto: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 <mailto:snappy-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/snappy-devel
>     <https://lists.ubuntu.com/mailman/listinfo/snappy-devel>
> 
> 
> 


-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150131/3c3eedda/attachment.pgp>