You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per this discussion on Zulip, we need to implement a concise way of dealing with multiple devices of the same class. Right now, we only support a single device per class, which severely limits our abilities to build more complex systems.
Inside Linux, USB devices are organized as a tree, for example:
~ $ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
This provides a useful starting point as this addressing system is easily scalable for daisy-chaining USB hubs. Moreover, most drivers provide a by-path symlink already, allowing us to connect directly to the device at a given port.
For instance, one of the video device listed above can be found at /dev/v4l/by-path/pci-0000:00:14.0-usb-0:5:1.0-video, where pci-0000:00:14.0 is the location of the root hub (integrated to the motherboard), usb-0 is the hub itself 5 is the port and 1.0 is the interface.
Therefore, my suggestion is that we provide a similar addressing scheme for our users. This would require rewriting each class and defining a user-friendly way to present the addresses. My suggestion is following the standard Linux convention, but stripping it from redundant parts like the PCI address. For instance, the device above could be reached by usb-0:5.
Rewrite digitalRelay
Rewrite network
Rewrite power
Rewrite SD mux
Rewrite serial
Rewrite video
The text was updated successfully, but these errors were encountered:
According to our discussions and findings on the Linux udev subsystem, we've decided to go with a simplified version of the Linux addressing scheme, where symlinks are handled by the autokit-server using udev rules.
The autokit npm library would then only receive the fully translated device paths, leaving the server/block tasked with doing any user friendly renaming.
In order to not have Leviathan do the setup of the udev rules, we should implement the Node version of udev here so that the package can operate on its own.
As per this discussion on Zulip, we need to implement a concise way of dealing with multiple devices of the same class. Right now, we only support a single device per class, which severely limits our abilities to build more complex systems.
Inside Linux, USB devices are organized as a tree, for example:
This provides a useful starting point as this addressing system is easily scalable for daisy-chaining USB hubs. Moreover, most drivers provide a
by-path
symlink already, allowing us to connect directly to the device at a given port.For instance, one of the video device listed above can be found at
/dev/v4l/by-path/pci-0000:00:14.0-usb-0:5:1.0-video
, wherepci-0000:00:14.0
is the location of the root hub (integrated to the motherboard),usb-0
is the hub itself5
is the port and1.0
is the interface.Therefore, my suggestion is that we provide a similar addressing scheme for our users. This would require rewriting each class and defining a user-friendly way to present the addresses. My suggestion is following the standard Linux convention, but stripping it from redundant parts like the PCI address. For instance, the device above could be reached by
usb-0:5
.The text was updated successfully, but these errors were encountered: