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. Cheers 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
