Consider providing a CDI spec file for USB-based cameras (Docker/containers)

[gavanderhoorn]

tl;dr: it would be greatly appreciated if Zivid could make a CDI (Container Device Interface) spec available for USB-based Zivid cameras to facilitate passing them through to containers.

---

original: for a project in which we use a Zivid One Plus M, we're trying to host the ROS driver (and required/related Zivid SDK) in a Docker container.

The camera is a USB device and actually enumerates quite a few devices, all of which seem to have to be available for the driver/SDK to work correctly (if we understand things correctly). The typical approach with Docker would be to pass device nodes to containers using --device (or sometimes as bind-mounts of actual device nodes).

As it's not completely clear which devices belong to the Zivid camera, we're currently passing /dev itself to the container. While this works, it's not very nice, as it pokes a big hole in the isolation typically offered by containers. It's also not always possible, either due to security concerns or other logistical barriers.

The container community has come up with a specification (CDI, the Container Device Interface) which allows to succinctly describe what resources would need to be made available to a container in order to "mount a device" and be able to use it from within that container. As a good example, NVIDIA supports CDI for its various GPUs and accelerators as they are/can be quite complex devices to properly expose to a container.

One of the main motivators for the creation of CDI seems to describe the characteristics of USB-based Zivid cameras well (emphasis mine):

On Linux, enabling a container to be device aware used to be as simple as exposing a device node in that container. However, as devices and software grows more complex, vendors want to perform more operations, such as:

• Exposing a device to a container can require exposing more than one device node, mounting files from the runtime namespace, or hiding procfs entries.
• [..]

Instead of reverse-engineering all the required devices and resources ourselves, I'm wondering whether Zivid would consider providing a CDI spec for their USB-based devices. It should make use of these devices in containers (not just Docker, but also Podman fi) quite a bit more straightforward.

If that would not be possible, some guidance on which devices are enumerated after connection of a Zivid One Plus M to a Linux-based OS would be appreciated. The community could then potentially come up with a CDI spec itself.

[gavanderhoorn]

I've posted this here in the zivid-ros repository, but any resulting CDI spec would not be ROS-specific at all.

It would be useful even if just using the Zivid SDK 'natively', without any ROS involvement.

[apartridge]

Hi @gavanderhoorn. Thanks for reporting this issue. It does seem like a CDI wrapper for Zivid One+ cameras would make sense. I wasn't aware of this feature. However, note that Zivid One+ has reached its end of life for future improvements and SDK upgrades, the last SDK to support it was 2.11. One+ will going forward only receive updates for critical bugs/fixes/security issues, when relevant. So for this reason we will not be able to prioritize this improvement for One+.

You are correct that One+ will enumerate a few USB devices. These USB devices below (vendor+product id) are being used by One+. I used lsusb with and without camera connected, to make this list. Hopefully these is sufficient for making the spec. Let me know if you need additional info.

0e70:001f 
0451:8025 
0483:a26b 
0451:6401 
0451:8027 

[gavanderhoorn]

thanks for your reply.

note that Zivid One+ has reached its end of life for future improvements and SDK upgrades, the last SDK to support it was 2.11.

that's probably true, but we still have these devices, so I have to get something to work :)

You are correct that One+ will enumerate a few USB devices. These USB devices below (vendor+product id) are being used by One+. I used lsusb with and without camera connected, to make this list. Hopefully these is sufficient for making the spec. Let me know if you need additional info.

0e70:001f 
0451:8025 
0483:a26b 
0451:6401 
0451:8027 

thanks. We'll see whether this is sufficient.