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@entry=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@entry=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@entry=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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
