> > Alternatively, you don't even need the complete HelenOS libc to implement > such a basic task as printing a string to the kernel console from user > space. You just need to implement simplified variants of the > > > following > functions (say for IA-32) and a few other things: > > > > __entry (from uspace/lib/c/arch/ia32/src/**entry.S) > > __syscall_fast (from uspace/lib/c/arch/ia32/src/**syscall.S) > > __main (from uspace/lib/c/generic/libc.c) > > klog_write (from uspace/lib/c/generic/io/klog.**c) If SPARTAN alone is chosen as the basis, it does not make sense to use the entire libc. You are interested in the code which helps you talk to the kernel. In the ideal case libc could be ironed out so that this code can be easily separated and reused.
> > The decision whether you should use the complete HelenOS libc or whether > you should create your own stripped down run-time library is an extension > of the question I have already written about previously: > > What should be the target software architecture of Genode/SPARTAN? Should > it be a complete HelenOS user land with Genode user land running > side-by-side? Should it be just the SPARTAN kernel with Genode > user land? > Or should it be a customized combination of both? If Genode runs on top of HelenOS userland, it's pretty much the same as Genode running as a Linux applicaton. If I understand correctly, running Genode as a userland application is considered more a debugging feature than anything else? Does it have some limitations? (E.g. not having complete control over HW resources?) Btw. I wonder what challenges await from runnning on top of SPARTAN. One thing that comes to mind is the loading of executables - how does that work in Genode? I thing HelenOS uses a rather uncommon approach, so there could be dragons hidden here. Sure, you can get the first process started by making it an initial binary, but what about when you want to create a new one? > I for my part would not consider using the > complete HelenOS userland necessary. But for example opening the > possibility to incorporate the one or another device driver from the > HelenOS userland could be quite useful. What do you think? You could certainly rip out the code of some driver and re-use it (or factor out, in case of some more complex driver). But you could hardly use any driver as-is, that would pull in almost everything else as a dependency. Any (non-DDF) driver depends on the async framework (in libc). Any DDF driver depends on the Device Manager which uses the file system :-) Cheers -Jiri _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
