feat: UIO backend support for multiple memory maps

[bellaz89]

UIO backend: support for multiple memory maps

Previously the UIO backend only supported a single memory-mapped region (map0) and rejected any
access to other maps. This MR extends it to support up to MAX_UIO_MAPS (5) regions, matching
the mainline kernel limit.

Changes

• Introduced UioMap as a private inner class of UioAccess, encapsulating the lifecycle of a
  single UIO memory region. It is move-only (copy deleted), uses RAII for mmap/munmap, and
  validates address bounds on every read/write with detailed error messages.
• Maps are lazily initialized on first access via getMap(), avoiding unnecessary mmap calls
  for regions that are never used.
• open() now probes the sysfs directory tree to count how many maps the device exposes, storing
  the result in _maps_number.
• mapIndexValid() is exposed publicly so UioBackend::barIndexValid() can delegate to it,
  replacing the hardcoded bar == 0 check.
• Removed the old UioMMap()/UioUnmap() helpers and the single-map fields (_deviceUserBase,
  _deviceKernelBase, _deviceMemSize).
• String construction throughout uses std::format (C++23) instead of + concatenation.
• Minor code quality fixes: = default constructor, nullptr for NULL, static_cast<off_t>
  for the mmap offset narrowing conversion.
• Add multiple map tests in testUioBackendUnified.cpp. Set BSP.* registers in uioBackendTest.mapp to map0, FCM.* registers to map2 and all other registers to map1.
• Add BROKEN.REG to unmapped map3 to check that the backend generates an exception on access.

Notes

Test passes on modified uio-dummy module of ChimeraTK/uio-dummy#18

[mhier]

I just had a quick glance, the general coding style looks good and modern. The formatting is not to our style tough, please run clang-format (if you use dragon, simply call ../format-ccode.sh in the source directory). Also please add the "chrome bar" comments (/******* full lengths) to separate all blocks at namespace level (i.e. between functions etc.).

The only "real" comment I have is that there are no tests. Do you feel confident enough to extend the tests/executables_src/testUioBackendUnified.cpp? I know the unified backend tests are hard to understand, so maybe someone from us has to do that... Also I don't know if this is even possible, since the uio dummy has to support this? @phako Can you comment?

[phako]

Not sure the dummy supports this either, but leaning towards "no"

[bellaz89]

I just had a quick glance, the general coding style looks good and modern. The formatting is not to our style tough, please run clang-format (if you use dragon, simply call ../format-ccode.sh in the source directory). Also please add the "chrome bar" comments (/******* full lengths) to separate all blocks at namespace level (i.e. between functions etc.).

The only "real" comment I have is that there are no tests. Do you feel confident enough to extend the tests/executables_src/testUioBackendUnified.cpp? I know the unified backend tests are hard to understand, so maybe someone from us has to do that... Also I don't know if this is even possible, since the uio dummy has to support this? @phako Can you comment?

Hi,

Where can I find ctkuiodummy required to run testUioBackendUnified.cpp? Is that a custom kernel module or? Or do you have a VM image where I can run the tests?

[killenb]

The dummy is available from the ChimeraTK github https://github.com/ChimeraTK/uio-dummy
For Ubuntu24.04 we have a debian package in the doocs/desy repo: uio-dummy-dkms

[bellaz89]

The dummy is available from the ChimeraTK github https://github.com/ChimeraTK/uio-dummy For Ubuntu24.04 we have a debian package in the doocs/desy repo: uio-dummy-dkms

Thank you.

In principle, I can look at it and try extending the module and and the tests.. Though I do not have kernel development experience. Therefore I will need some time to see if I am able to do the required modifications.

[bellaz89]

Additional test-related changes:

• Add multiple map tests in testUioBackendUnified.cpp. Set BSP.* registers in uioBackendTest.mapp to map0, FCM.* registers to map2 and all other registers to map1.
• Add BROKEN.REG to unmapped map3 to check that the backend generates an exception on access.

Notes

Test passes on modified uio-dummy module of ChimeraTK/uio-dummy#18