May-15th-2019, 10:06 AM
We already have a lovely netpi device. I'm currently not able to test it, but I researched a bit on the topic and their are still some options to try:
Instead of mounting a --device,
1) according to this post [1] it might work to set the --privileged flag and mount /dev/bus/usb and then work manually on it with a script like in [2]
2) mounting the /dev/usb/ as volume as well as /run/udev [3] such that udevadm is able to retrieve information from the hosts udev system
3) combination of 1) and 2)
4) maybe it is possible to use udev inside the container by providing fine-grained access to required host system directories...
We'd also need this functionality for serial devices.
It would be an improvement, if the USB devices would be present in the container dynamically without compromising the host system and featuring udev metadata for manual processing, although udev.rules like creation of device symlinks (maybe with modified script from 1)) would be better.
EDIT:
OK, I did test with the hilschernetpi/rpi-raspbian image and saw that both /dev/bus/usb and /run/udev is not allowed to be mounted as volumes. So if we stick to the idea of bringing usb and serial devices into something like /dev/usb and /dev/serial which can then be mounted as a volume(?) we could then maybe make the symlink to hold the ID information according to an answer in [3] with a udev.rule like this: "SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"" So maybe it is possible to populate the information for the symlink.
As I understand it, the udev info is not present within the container for SYMLINK+= dev paths because /run/udev is not present in the container. Since we cannot get access to this, might it be possible to use udev on the host system and work around the problem by invoking a script via udev.rule for every usb/serial device which additionally to symlinking into /dev/usb creates a yaml file with the udevadm info content? This would be enough to programmatically check devices and read their information from something like node-red. What do you think?
[1] https://stackoverflow.com/questions/2422...ial-device
[2] https://www.guidodiepen.nl/2016/05/notif...container/
[3] https://stackoverflow.com/questions/4175...-container
Instead of mounting a --device,
1) according to this post [1] it might work to set the --privileged flag and mount /dev/bus/usb and then work manually on it with a script like in [2]
2) mounting the /dev/usb/ as volume as well as /run/udev [3] such that udevadm is able to retrieve information from the hosts udev system
3) combination of 1) and 2)
4) maybe it is possible to use udev inside the container by providing fine-grained access to required host system directories...
We'd also need this functionality for serial devices.
It would be an improvement, if the USB devices would be present in the container dynamically without compromising the host system and featuring udev metadata for manual processing, although udev.rules like creation of device symlinks (maybe with modified script from 1)) would be better.
EDIT:
OK, I did test with the hilschernetpi/rpi-raspbian image and saw that both /dev/bus/usb and /run/udev is not allowed to be mounted as volumes. So if we stick to the idea of bringing usb and serial devices into something like /dev/usb and /dev/serial which can then be mounted as a volume(?) we could then maybe make the symlink to hold the ID information according to an answer in [3] with a udev.rule like this: "SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"" So maybe it is possible to populate the information for the symlink.
As I understand it, the udev info is not present within the container for SYMLINK+= dev paths because /run/udev is not present in the container. Since we cannot get access to this, might it be possible to use udev on the host system and work around the problem by invoking a script via udev.rule for every usb/serial device which additionally to symlinking into /dev/usb creates a yaml file with the udevadm info content? This would be enough to programmatically check devices and read their information from something like node-red. What do you think?
[1] https://stackoverflow.com/questions/2422...ial-device
[2] https://www.guidodiepen.nl/2016/05/notif...container/
[3] https://stackoverflow.com/questions/4175...-container
