cifx in docker

[simonschmeisser]

One of our customers wants to run our software in a docker container. I tried exposing /dev/uio0 to the docker container but fail to open the device from inside.

sudo docker run --device=/dev/uio0 --rm -it --entrypoint bash our-image:1.2.3

rosrun profinet_io profinet_io 
[INFO] [1719933629.397217264]: Starting Profinet IO node...
[INFO] [1719933629.405169805]: Starting up Hilscher card: ConfigurationId = 0, Input data length = 64 bytes, Output data length = 64 bytes
Error adding automatically found cifX device @ Phys. Addr 0xF6800000. (Status=0x800A0013)
[ERROR] [1719933630.013678862]: Error opening SystemDevice!

[ERROR] [1719933630.013733945]: [Mikado Profinet] Failed opening system device, either the kernel module "uio_netx" has not been loaded or the module description in /opt/cifx doesn't match please see also the text above for hints
Error: 0x800A0002, <No board with the given name / index available>
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed opening system device
Aborted

Has this been tried before? Any hints? The customer would prefer not to use a privileged container.

[MTrensch-hilscher]

There usually is a logfile (depending on trace level set on driver init) which shows more detailed information about what is failing.

I assume it's rewriting the PCI configuration space, which is required after resetting the device, as it "forgets" it's PCI configuration data. This is done using the pciaccess library which rewrites this data via sysfs (which is usually mounted read-only inside a container)

See excerpt from documentation:

libcifx (Toolkit) needs to run as 'root' or with a user that has the following rights:

• read/write access to the PCI configuration registers
• (i.e. '/sys/class/uio/uio/device/config')
• Mapping of DPM to user space (see 'mmap' and 'ulimit -l')
• read/write access to devices '/dev/uio'

• read/write access to /dev/mem (for user added devices)

  Running as root means privileged mode, when using a container.

You will either need to make sure that pciaccess library is able to restore configuration data (write access to /sys/class/uio/uio/device/config is hopefully enough, but may be tricky due to many symlinks in sysfs)

Another unofficial possibility would be to try the patch attached to https://ticket.hilscher.com/projects/NXDRVLINUX/issues/NXDRVLINUX-142 which get's rid of pciaccess library and provides an updated uio_netx that provides a sysfs file (/sys/class/uio/uio0/device/pcicfg) for rewriting configuration space. But this has neither been intensively tested, nor is officially supported