Linux IO_MEM session

[Johannes Kliemann]

Hi Norman

thanks for your help.

> 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.
So if I understand it correctly just opening the file and calling
_ds.fd(fd) would be enough (beside having the Dataspace_component _ds)?

I implemented this but when I try to attach the dataspace I get a
segfault. I though this might be related to a wrong physical address for
the file but the backtrace leaves me completely clueless.


> #0  pseudo_end () at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29
> #1  0x000000000109d7c1 in lx_futex (val=0, op=0, uaddr=<optimized out>) at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/linux_syscalls.h:350
> #2  thread_stop_myself () at /media/sf_kernel/genode/repos/base-linux/src/include/base/internal/lock_helper.h:66
> #3  Genode::Cancelable_lock::lock (this=this at ...551...=0x80ffae0) at /media/sf_kernel/genode/repos/base/src/lib/base/lock.cc:123
> #4  0x00000000010b19c8 in Genode::Lock::lock (this=<optimized out>) at /media/sf_kernel/genode/repos/base/include/base/lock.h:33
> #5  Genode::sleep_forever () at /media/sf_kernel/genode/repos/base/src/lib/base/sleep.cc:21
> #6  0x0000000001065eb8 in Genode::Signal_receiver::block_for_signal (this=this at ...551...=0x64b4a70 <Genode::bootstrap_component()::startup+3472>)
>     at /media/sf_kernel/genode/repos/base/src/core/signal_receiver.cc:49
> #7  0x0000000001096a70 in Genode::Entrypoint::_process_incoming_signals (this=this at ...551...=0x64b3e40 <Genode::bootstrap_component()::startup+352>)
>     at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:108
> #8  0x000000000109772e in Genode::Entrypoint::Entrypoint (this=0x64b3e40 <Genode::bootstrap_component()::startup+352>, env=...)
>     at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:329
> #9  0x00000000010915ac in Genode::Startup::Startup (this=0x64b3ce0 <Genode::bootstrap_component()::startup>)
>     at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:244
> #10 Genode::bootstrap_component () at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:259
> #11 0x00000000010cd016 in _main () at /media/sf_kernel/genode/repos/base/src/lib/startup/_main.cc:248
> #12 0x0000000000000000 in ?? ()

Regards,
Johannes