Hi Johannes,
The required device on Linux is already available (if you're interested, I've written a kernel module to provide it in [1]) so that isn't the problem.
cool!
I tried to implement the IO_MEM session on base-linux but lack the understanding of how the Linux_dataspace and the Io_mem_dataspace are different. On base the Io_mem_session_component gets the dataspace capability from
_ds_cap = static_cap_cast<Io_mem_dataspace>(_ds_ep->manage(&_ds));
This doesn't work with base-linux since I can't cast the Linux_dataspace to Io_mem_dataspace. Yet I don't understand what I need to do this.
On base-linux, there exists a custom 'Dataspace_component' implementation. In contrast to the regular version that maintains the information about the dataspace's physical address, the base-linux version has a file descriptor as member variable and the setter 'fd' to assign it. For RAM dataspaces, the file descriptor is assigned by (the Linux-specific implementation of) 'Ram_dataspace_factory::_export_ram_ds'. For ROM dataspaces, the file descriptor is assigned by the 'Dataspace_components(args)' constructor.
Your approach of introducing a base-linux-specific version of 'io_mem_session_component.h' is good. Like in the regular version, it hosts a 'Dataspace_component' object. But additionally, it would obtain the file descriptor from your kernel driver and assign it to the dataspace object. This could be done in the constructor (which now just prints the warning message). Once assigned, the rest (in particular the passing of the fd to the clients via RPC) should work out of the box.
For a quick test to see if the fd-passing over component boundaries works, you may first open just a regular file with known content and let an IO_MEM client (living outside of core) attach the dataspace and print its content.
Cheers Norman