Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize a way of dealing with multiple devices of the same class #45

Open
6 tasks
phckopper opened this issue Jan 19, 2023 · 3 comments
Open
6 tasks
Labels
enhancement New feature or request

Comments

@phckopper
Copy link
Contributor

phckopper commented Jan 19, 2023

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
@phckopper phckopper added the enhancement New feature or request label Jan 19, 2023
@phckopper
Copy link
Contributor Author

Related #29

@phckopper
Copy link
Contributor Author

phckopper commented Jan 26, 2023

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.

More information on the server repo soon.

@phckopper
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant