Initial phase of the feature will target USB devices, as it’s obviously extremely popular and provides the right metadata.
Today for a core device to support custom devices in a nice way via interfaces the only solution is to have the slots on the gadget snap, which is not ideal.
For it to work snapd has to understand the idea of USB devices showing up at any point. Some of that is already done for other reasons today (auto-import).
Also needs a way to pattern match the data that the bus offers snapd, to define which specific interface, and with which attributes that slot should be made available into the system.
Once devices go away, we disconnect (run hooks, etc), remove the slot from the system, but keep the data about the state it was, including which connections were made, and which auto-connections were disconnected.
Once the device shows up again, we recreate the slot, reestablish the state as closely as possible, including reconnections, hooks, etc.
Slots might be named after the we receive via udev, but we need to investigate if we can create good heuristics for that. It’s better to have a sequential number on top of the interface name (serial-port10) than to have a very dirty name.
We might use the interface label as more verbose data coming from the device to describe it, and then have a way to list it.
