test: docker: Support sharing /dev nodes using --mount docker option
In device type template, one can set:
actions: test: methods: docker: share_devices: direct
share_device option value can be:
- udev (default, in case the value is not set or empty) - previous behavior, rely on udev event forwarding, which requires additional software running on the host (e.g. lava_dispatcher_host).
- direct - pass device nodes on docker command line using --mount option (a more obvious --device option is not used, because it doesn't allow device name to contain ':', which is otherwise often the case). Only real device nodes are shared, symlinks (as usually created by udev on the host) aren't.
- direct-symlinks - like above, but symlinks are shared too. Note that such symlinks become real device nodes in the container, which may pose problems with some software. (E.g. if software blindly expects a particular node to be a symlink, and calls readlink() on it. This was seen e.g. with mbedOS tools).
Direct sharing of the devices is mostly implemented by 2 reasons:
- When LAVA itself runs in a docker container(s), it's yet an open question how to perform udev forwarding (lava_dispatcher_host isn't currently a part of the official docker-compose setup for LAVA).
- Even if forwarding works, it apparently requires udev to be running in a container to be the receiving side of this forwarding. But that's oftentimes not the case (udev is not included in docker images), which would require patching such docker images specifically for LAVA, which is not always practical.
So, choice of sharing device nodes using native docker means is provided. This isn't fully optimal/general solution either, e.g.: a) it apparently won't work with dynamically appearing/disappearing device nodes; b) there're issues with symlinks, device nodes containing ':', and capabilities/permission required to access them (--device doesn't work with ':' in device names, so we have to use --mount instead; but mount requires using --privileged for most operations on the device nodes, while --device would require only particular --cap-add option).
That said, with these new options, there's not a good inventory to solve different usecases, with this fairly peculiar area of operating on device nodes in docker containers, which is kind of fringe area, lying outside the original docker usecases, and which still requires further evolution upstream or robust external tools (like lava_dispatcher_host, which itself doesn't cover all the usecases yet).
Signed-off-by: Paul Sokolovsky firstname.lastname@example.org