UPDATED 2018/04/17 after discussing some high-level ideas with Gustavo; most important change is the removal of event filters.
This is a high-level proposal of the HotPlug implementation (for USB initially), as a followup to the general plan discussed during last sprint and documented here: Development sprint March 5th, 2018 .
Prior to writing the notes below I did some experimentation with go-udev package (https://github.com/pilebones/go-udev) and it seems to be a nice candidate for doing the low-level bits for us. The main factor when looking for suitable udev-handling package for go was no reliance on cgo (we want a native Go implementation).
High level overview
New “UDev Monitor” in snapd will be responsible for monitoring for udev hotplug events and enumerating already existing devices on start. It will internally use go-udev or similar (but will hide some of its implementation details) to discover devices, and will also collect some extra attributes (such as idProduct and idVendor) when new device is reported, along with data normally present in uevent. UDev Monitor will report all hotplug events (devices added/removed) and ifacemgr will pass them down to all interfaces that implement the needed hotplug methods.
Reported events will be handled by ifacemgr. One way of doing this would be via tasks created by UDev monitor and handled by ifacemgr. Events reported by UDev Monitor will be passed to all interfaces that implement the needed hotplug API method. It’s perfectly fine for an event to be handled by more than one interface - for example, plugging a device results in read-only access via foo interface and write-access via foo-control interface.
Interfaces interested in hotplug devices will need to implement the following new method:
- HotPlugDeviceKey: method that generates a unique key for given device, based on the data provided by UDev Monitor (e.g. a combination of productId + vendorId + serial); we will provide a default implementation of device key computation, but interfaces will be allowed to provide their own. The key will be used to recognize devices as they are unplugged and plugged again.
- HotPlugDeviceAdded: method that receives hotplug event data (wrapped in a convinient object) as well as a “hotplug backend” object. The method decides if particular device is relevant for this particular interface and if so, produces a definition of a slot using the backend object.
Hotplug devices repository
Interface Manager will maintain a list of hotplug devices that were handled by interfaces - every supported device will have an entry in the state: its unique device key, list of slots and list of connections that persists even if device is unplugged), for example:
"hotplug": {
"<devicekey>" : {
"slots": [ <slot refs> ],
"conns": {
"<connref>": true,
},
}
}
Note: the hotplug conns here are independent from existing global conns structure we have right now. When a hotplug device has connections, the connection appears both here in hotplug conns and in global conns. If it’s disconnected with snap disconnect ..., it disappears from both structures. If however the device is unplugged while connection was active, the connection is only removed from global conns and remains in hotplug conns.
This hotplug map will obviously need to be kept in sync with installed snaps - if snap gets removed, it disappears from hotplug conns. We will however never remove devices from it, as we have no way of knowing if the device ever comes back.
Sample flow
A sample execution flow based on the above plan will look as follows:
- Camera is plugged to the USB port.
- UDevManager receives uevent, creates a new “hotplug-add” task and puts all uevent data in it (device name, env data) and idProduct, idVendor, serial., e.g.
{
“device”: “/sys/devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/video4linux/video0”,
“env”: {"MAJOR":"81" "MINOR":"0" "DEVNAME":"video0" "SUBSYSTEM":"video4linux"},
“idProduct”: “57c3”, “idVendor”: “0bda”, “serial”: “200901010001”
}
- The “hotplug-task” is picked by ifacemgr handler,
- ifacemgr passes device data to all interfaces that implement HotPlugDeviceAdded method; default device key is computed unless the interface provides own HotPlugDeviceKey method.
- The implementation of “camera” interface creates slot defintion.
- The slot gets added the interfaces repository.
- Interface Manager consults its internal hotplug devices repository to see if the device was already known based on its device key and if so, the previous name of the slot is used. If the slots were connected, re-create the connections and run interface hooks.
Implementation steps
I’ve broken the implementation into steps with the intent of being able to do the work incrementally in a series of PRs; this is just a rough idea and the order and details are not neccessarily very precise.
- UDevMonitor as a new entity in snapd. Enumerates all existing devices and monitors for new ones. Doesn’t do anything about them just yet.
- Defintion of new interface methods (HotPlugDeviceAdded, HotPlugDeviceKey…), definition of the structs passed to these methods (udev event data, “backend” object to act on when adding new slot).
- Implementation of hotplug device repository in ifacemgr.
- Implementation of method that creates device key based on all attributes of the deivice
- Stubs for “hotplug-add” and “hotplug-remove” handlers.
- Implement “hotplug-add” task handler of ifacemgr: call the right interfaces, create slots on the fly.
Insert slots into the repository. - Implement “hotplug-remove” task handler of ifacemgr: disconnect hotplug slots.
- Autoconnect slots on hotplug where appropriate.
CC @niemeyer
