Snappy capabilities, in baby steps

[Zygmunt Krynicki]

On Fri, Nov 13, 2015 at 5:47 PM, Ted Gould <ted at ubuntu.com> wrote:
>
> Uhm, okay. Typically I prefer to map the landscape first, but okay.

For now (which may or may not change later) there will be a mechanism
that can create capability instances. Snaps may get access to those
capabilities when the user assigns them (similarly to how hw-assign
works now but instead of a file you will assign a named capability).

Later on there are some interesting ideas but that's what I want to build today.

> So from Zygumnt's thread it sounds like there's going to be a tag cloud
> attached to each snap. I'm guessing that this is going to include kernel,
> gadget and framework snaps. They'll export which tags they support. Will the

Snappy will know about capabilities centrally. This will come from
various sources (see below). Capabilities are more than just tags
(think a struct with some data inside) but indeed all capabilities
will have an unique identifier (that is meaningful to the particular
system but not universally) and a kind or type (that is meaningful
universally but not unique in a system).

> tags be centrally defined or are we hoping for some sort of emergent
> behavior here? How will we handle conflicting tags?

I think that we need central definition of capability types (kinds)
but not instances (capabilities). Types will define the permission
grants that are applied to snaps that are given a certain capability
by the user. Those need careful design and review. Actual capabilities
on the other hand can be easily created by whoever wants to make a new
device that has Ubuntu on it. The goal of that person should be to
expose the hardware in a way that is useful for applications using the
common vocabulary that is centrally defined.

> For the cases where versioning is important, how will that be handled. For
> instance being able to support OpenGL could mean standard GL of various

I strongly believe stuff like graphics will be consumed by snaps that
talk to other snaps (e.g. mir framework). Actual mir might get
assigned to a low-level capability that just grants access to all the
device nodes required to implement mir itself. It is not something you
will usually assign to a random application.

> versions or GLes of various versions. For games which versions the HW can
> support can be very important.

I have an idea about how to do versioning (specifically of the type of
the capability, not the capability itself) but that is really
premature at this stage. I think versions are necessary as they define
a contract between the person making the hardware, canonical and the
person making the application and we clearly want to have a good and
predictable behaviour there.

I think we can safely assume we'll support versions but exactly how,
if the idea I have is useful, is not sure. I might discuss that idea
but it's still a few weeks before the prerequisites are there to make
the discussion meaningful.

> There was a mention of passing metadata, which way will the metadata
> transfer occur? Both? What is the lifecycle and policy for handing that
> passing of metadata? Does it require a particular format or is that to be
> decided by the framework and/or application involved in the exchange?

Right now the OS snap will create capabilities. Later on the gadget
snap will have a say so that on a particular device, with imperfect
detection data you can still correct that for users and applications
to consume sensibly.

I have ideas on how snaps can also participate as capability creators
but this is pretty hazy and I don't want to go there now. There are
plenty of interesting use-cases that can be made but I have a feeling
that capabilities and "frameworks" (as things you talk to to gain
access to something they manage) might be contending to handle the
same thing in that case. From another point of view it makes perfect
sense as a filtering mechanism.

> I hope that'll start the conversation some.

I'd love to discuss bits but I'd like to focus on the simple (as in
obviously correct) things that I'm working on now and the +1 step
after that. Otherwise we'll easily go back to the grand-design idea
and I think it won't work well

For now my goal is to make it possible to define and assign a
capability as simple as a single device node so that "snappy hw-assign
$incomprehensible_thing" can be replaced with "snappy
assign-capability $useful_name $snap_name".

Best regards
ZK