Hello Norman, Thank you for your detailed explanation. Yes. I understood the importance of the back end between library and Genode and hence provided the implementation that looks similar to the libc back end but I forgot to mention it in earlier mail. So far, it looks fine for me.
For the situation just mentioned above(stdio.h exclusion and Genode namespace inclusion in repos/libports/src/test/libc/main.cc, I have attached the file as reference) it looks like the printf's in main.cc are completely bypassing the library(not touching the functions of libc). Is it not?? If it is, then it is using the printf() in Genode directly with out using the plugins of libc and hence the printf's in bionic's testing main.cc(same as attached) should also need to print right?
As per the debug messages that I have, bionic is exactly stopping just after the parsing of config (taking the file path given to stdout). Am I missing out something here?
On Wed, Apr 22, 2015 at 7:20 PM, Norman Feske <norman.feske@...1...> wrote:
Hello Paramesh,
On 04/22/2015 12:20 PM, Paramesh Oddepally wrote:
But, in my library(bionic), the same thing is not working afterthe same changes as above(with same main.cc ). Its not printing anything and waiting infinitely. I cannot understand how to interpret this problem, Is it problem with Library?
The run file of my library is similar to the /libc/ run file.merely compiling the library for Genode is merely the first (and probably the easiest) step of porting a C runtime like Bionic to Genode. The main part of the work is the creation of a libc "back end" that acts as the glue between the C runtime and the underlying Genode system. To give you an idea of the role of this glue, here are two examples:
The back end has to provide the memory for the C runtime's malloc and free functions. On Linux, the back end of the C runtime performs a mmap system call to obtain chunks of anonymous memory to be used at malloc/free backing store. On Genode, your back end would have to use Genode's RAM session and RM session interfaces instead.
For input and output (I/O), the back end has to translate I/O function calls (like read, write, stat, etc) to Genode's various session interfaces (terminal session, file-system session, log session, etc). This is far from trivial because, unlike a POSIX system, Genode does not have mechanisms that perfectly correspond to the C runtime function calls. For example, on Genode, there are no file descriptors. So the back end of the C runtime needs to emulate the semantics of file descriptors by using Genode's mechanisms.
To implement a back end for the Bionic C runtime, you may take cues from the back end of our existing libc, which you can find at [1]. But in order to go ahead, you will ultimately need to gain a good understanding of the internal structure of the Bionic library.
I would start with stdout (as you just tried). You first need to determnine the back-end function called by the Bionic library when issuing the printf function, e.g., by following the call graph within the Bionic library. On a Linux system, the back end of the Bionic libc will eventually issue a "write" system call. Your custom back end would instead issue a call to Genode::Log_session::write.
[1]
https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libc
Good luck! Norman
-- Dr.-Ing. Norman Feske 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
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main