Capabilities and slots
rick.spencer at canonical.com
Wed Jan 20 14:08:23 UTC 2016
On Wed, Jan 20, 2016 at 8:57 AM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:
> There's also an important detail missing from that description which I
> assumed to be known because it hasn't changed since we started talking
> about capabilities, but for completeness it'd be worth talking about it in
> this context.
> A capability slot may only have capabilities assigned to it if both have
> the same capability type. That's what defines compatibility between a
> capability and a capability slot. The capability name and slot name are
> local to the snap itself. As a concrete example, we may have a snap
> providing a capability "pin-13" that is assigned to a capability slot
> "led", so we can turn some led on and off when the pin goes high/low. Both
> the capability and the slot must have a common type (e.g. "bool-file") for
> it to work.
For my own education, would it be possible for someone to expand on this
example a little?
I assume that as a developer I would somehow also have to map the snap to
the actually GPIO pin in order to grant the snap permission to use that
hardware. Perhaps this is an erroneous assumption now? Would it be possible
to briefly describe how I will use capabilities to grant access to things
like /sys/class/gpio/export and /sys/class/gpio/gpio13/direction (and
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the snappy-devel