Hi Genode Engineers.
I've been following the Genode project for a few years, and I'm very excited about it's progress. I've worked through some of the build instructions, and read most of the documentation on the website. I've been able to test out various run files, and I want to begin porting some stuff. I just have a few questions, which would help me understand how you envision the system level considerations.
1. Do any library level diagrams or flowcharts exist? Specifically to describe at which point various pieces funnel together? Maybe something with details comparable to Linux_Graphics_Stack_2013.svghttp://upload.wikimedia.org/wikipedia/commons/c/c2/Linux_Graphics_Stack_2013.svg ?
2. How are shared configuration files handled? For example, system level configurations often found in /etc?
Thanks Everyone, -J.
Hello,
thank you for your encouraging words and welcome to the list!
- Do any library level diagrams or flowcharts exist? Specifically to
describe at which point various pieces funnel together? Maybe something with details comparable to Linux_Graphics_Stack_2013.svg http://upload.wikimedia.org/wikipedia/commons/c/c2/Linux_Graphics_Stack_2013.svg?
It is quite difficult to capture Genode using such a diagram because the architecture depends pretty much on how its components are composed. However, there exists a slide set that I assembled last year for a summer school. It contains several illustrations of Genode. Hopefully you may find it useful:
http://genode.org/files/slides/summer_school_2013_slides.pdf
- How are shared configuration files handled? For example, system
level configurations often found in /etc?
Generally, there is no convention about sharing or naming configuration files. Genode's configuration concept works quite different from what we know from traditional systems: A process obtains its configuration by requesting a ROM module called "config" from its immediate parent. It is up to the parent to decide how to handle such a request. For example, the init process usually handles it by handing out a snippet of its own configuration to the respective child. See the attachment for an illustration of how it works. Alternatively, the parent could dynamically generate the "config" data for its child (see ' os/src/test/dynamic_config/master/main.cc' for an example). Or, it could request a different ROM file from its own parent and hand it out as "config". For example, this can be done using init's '<configfile>' feature (see 'os/run/demo.run' for an example).
Of course, you could create a Genode system where all configuration files are stored on a central file system, following a system-global convention. There is even a component to make files of a file system available as ROM modules (see 'os/src/server/fs_rom'). But the important point is that Genode does not rely on such a convention.
Best regards Norman
-
J. M. Becker -
Norman Feske