additional base linux core

Norman Feske norman.feske at ...1...
Wed Oct 18 11:12:44 CEST 2017

Hi Johannes,

On 17.10.2017 17:55, Johannes Kliemann wrote:
> Yet I'm not sure what the way to go is:
>  - Copying the contents of base-linux into a new repository would
> probably make an easy start but lead to code duplication (and I would
> probably have to port all updates of base-linux).
>  - I already tried to reinclude the contents of base-linux (my
> repository currently only consists of Makefile fragments). Even though
> it builds it's often quite hacky to relocate some of the $(REP_DIR)
> entries to base-linux without breaking $(REP_DIR) itself. Also external
> libs sometimes don't seem to find the correct headers.
> - Directly extending base-linux would avoid these problems but this
> would require either a switch to choose between the original and the new
> functionality of this core or even better a "hybrid" core that is able
> to run in both environments. Also this change would probably need to get
> upstream (I don't know if this kind of change would be a problem generally).
> What is the recommended way to do this?

I definitely recommend the third way as I am quite positive that a
"hybrid" core is realistic. I also goes without saying that I'd love to
merge the outcome of this line of work to the upstream version.

As far as I can see, the differences of using core in both environments
is the use of core's IRQ, IO_PORT, and IO_MEM services. When using core
hosted on Linux like today, those services remain unused. But when using
core as init process or at least as a process with root privileges on
top a "microkernelized" Linux kernel, user-level device drivers will
open sessions to those services. So the distinction of both cases can be
hidden in the implementation of those services.

E.g., to enable core to access I/O ports in your new version, core must
call 'iopl', which is not allowed for normal Linux user processes. For
the regular base-linux, this is of course not needed and should be
skipped. By placing the 'iopl' call in the constructor of
'Io_port_session_component' instead of core's initialization code, the
same version of core can be used in both environments.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list