<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>Thanks for the update Zygmunt, it fills in a lot of holes for me, and I hope for others as well.</div><div><br></div><div>On Tue, 2015-11-17 at 14:55 +0100, Zygmunt Krynicki wrote:</div><blockquote type="cite"><pre>More and more bits are landing so I've started exploring a simple
scenario. An application that need to access a device that is normally
1) not known at compile time 2) not accessible to confined snaps.
</pre></blockquote><div><br></div><div>I think that I can infer from the rest of the text, but I want to double check, you'd expect the <i>type</i> to be known at the package build time, just not the configuration of that.</div><div><br></div><div>I'm concerned about the types because that will be the difficult part from the developer experience perspective. How they get a list of types and what the properties are so that we can generate reasonable errors if they misuse them.</div><div><br></div><blockquote type="cite"><pre>Let's use some hypothetical command line extension to snappy to create
and assign a capability
$ snappy create-cap serial-debug "Debug serial port" serial-port path=/dev/ttyS0
Here the create-capability is the new command. "serial-debug" is the
*name*, "Debug serial port" is the *label* and "serial-port" is the
type. What follows after is a set of key=value pairs that define
attributes. Here we just say that the "path" attribute should have the
value "/dev/ttyS0".
</pre></blockquote><div><br></div><div>It seems like this would be done by the gadget snap on most devices, no? So is there associated YAML that the gadget snap would have for configuring the board layout? Do you expect it to be adjustable by device owners or only those with a "developer mode" gadget snap?</div><div><br></div><blockquote type="cite"><pre>What happens here is partially obvious, partially open to discussion.
At a fundamental level, snappy needs to remember this fact, adjust the
security system and notify the application *somehow*. The way this can
happen is open to discussion. Right now I'd like to try the most
basic, easy-to-use method that can be safely extended over time. I'd
like to add a new hook, "assign" (and unassign later, for parity).
</pre></blockquote><div><br></div><div>I'm still against the hook. It seems to me that you're trying to use exec() as a form of IPC when we already have a better one implemented, REST. Marshalling variables through the environment is well understood, but also very tired.</div><div><br></div><blockquote type="cite"><pre>The application (or a wrapper) would read the config file mentioned
above to know which serial port to open. The unassign hook could
simply remove the file based on the same information.
</pre></blockquote><div><br></div><div>On place where hooks fail is if the config file needs to be regenerated, please also provide a mechanism to "query my current capabilities" so that I can check on them and rebuild the config file.</div><div><br></div><div>Also, it seems like your proposal doesn't take into account multiple sockets on the application side. For instance, if my application was "say yes or no over serial" I might want to hook up one serial port to one socket and another to a different. Something like:</div><div><br></div><div><font face="monospace">$ snappy assign-cap serial-debug-1 say-yes-or-no-over-serial-port yes-socket</font></div><div><font face="monospace"><div><font face="monospace">$ snappy assign-cap serial-debug-2 say-yes-or-no-over-serial-port no-socket</font></div></font><div><br></div><div>Shouldn't be hard to add, but just to ensure it gets into the structures and definitions early.</div><div><br></div><div>Ted</div></div><div><br></div></body></html>