This topic is to discuss some issues related to autoconnect handling in the upcoming hotplug support in snapd.
Some background first. Hotplug-aware interfaces can be implemented as:
- completely new types of interfaces - for concrete example think of existing camera interface that allows access to all cameras in the system and a separate hotplug-camera interface type which gives access to a very specific camera (separate instance of this interface for every camera in the system). If implemented this way, it means an “old” camera plug is not compatible with hotplug-camera slot.
- extensions to existing interfaces - old interfaces simply implement the new hotplug API method to create a hotplug slot when appropriate device appears in the system. Following above camera example, this means that when you plug a USB camera you see two slots in the system: an implicit camera slot that always exists (even if there are no cameras) and an additional hotplug slot named after your camera (e.g. hdwebcam-1). The type of both interfaces is camera and both will accept plugs of camera type, the difference however is in the permissions and runtime behavior: the old camera slot has very generous permissions (all cameras in the system), while the hotplug-aware hdwebcam-1 is tied to your specific device, it will understand when your camera gets unplugged and plugged back and if its device path changes, it will update security profiles accordingly.
For the prototyping of hotplug-aware extensions to camera and serial-port interfaces I chose the second approach as it’s backward compatible, however this revealed the following problems:
Issue 1
First and foremost, the fact that you have a hotplug-created slot and an implicit “old-style” slot at the same time is confusing. Backward compatibility is the problem though. The hotplug-created slots have some metadata stored in the state to tie them to specific devices, so it’s not easy to simply drop the old implicit slot and migrate existing connections to a hotplug-aware version of it.
Issue 2
Interface descriptions are shared among the existing implicit slot and a hotplug slot of same interface, which can be confusing. For example, the description of camera interface says “allows access to all cameras”; the dvb interface is similiar (“allows access to all DVB (Digital Video Broadcasting) devices and APIs”). The serial-port is an exception as it is narrowed down to a specific port even in its existing non-hotplug version and the description reflects this already (“allows accessing a specific serial port”).
Issue 3
Autoconnect refuses to autoconnect the above interfaces, since with hotplug we get two instances of every interface: the “old” implicit interface, and a specific hotplug slot. Autoconnect logic as currently is needs exactly one candidate slot to work.