Hi Tobias, On 25.06.2012 15:55, Tobias Börtitz wrote: > Hey everyone, > > since I have been quite busy with university related stuff my weekly > report is dropping in a bit late. Sorry for that. > First of all I updated the used HelenOS revision. This was to include > the arbitrary stack size improvement made by Martin (thank you for the > very fast reaction and implementation on this issue). I updated the > thread-creation-test to use the new implementation.
I also want to thank Martin for his prompt help! Unfortunately your updated syscall bindings doesn't compile anymore: /home/kalle/src/genode-labs/genode/base-spartan/src/lib/platform/syscalls.cc:66:7: error: ‘uspace_arg_t’ has no member named ‘uspace_stack_size’ make[3]: *** [syscalls.o] Error 1 Is it possible that you forgot to commit certain changes? > Then I took the ipc_send_wait test from the OKL4 tree (out of the Genode > repository) and initially implemented the required classes. The test > task is spawning a new thread which is then sending a message to the > creating thread. As temporary workarounds the used naming service is > still forwarding the connect_me_to call and the worker threads are still > directly accessing the tasks answerbox. > Genode specific: Since the Ipc_istream inherits from the > Native_capability, and there is no possibility to overwrite the _dst > variable I had to put the sender-specific attributes into the class > Msgbuf_base instead of the Cap_dst_policy. Native_capability is the platform-specific class, the Capability class inherits from. So it's almost completely up to you how to implement it including any setter-methods to change '_dst'. If the 'Native_capability_tpl' template you're currently using, which is sufficient for most platforms doesn't allow you to do so, you don't have to use it at all. Please, have a look at the Native_capability class for Fiasco.OC (base-foc/include/base/native_types.h) for an example where the template isn't used. > This is because the sender > specific attributes are being filled not at the creation of the > Ipc_istream var, but later on. Is this ok for you or is there a better > way to deal with this? No it's really better to put connection details into the capability class itself. One and the same capability might be used by different message-buffers. It's logically separated. As stated earlier a capability also can be transfered via IPC into another task. > For week 6 I plan to implement: > - connection creation via cloning an existing one I'm curious about your findings here. > - sending the thread-id of the destination with every syscall > - implement a manager thread for every task and make the worker-threads > use a thread-specific call queue to receive calls > If you have any questions or ideas / thoughts please let me know. > > Regards, > Tobias Best regards Stefan -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
