<div dir="ltr"><div>Hi Norman,</div><div><br></div>Thanks for the detailed suggestions with so much patience. I'm a practitioner, so I really appreciate details, and I'll check out the stuff that you've mentioned and try to get started ASAP.<div><br><div>BTW, do you have any suggestions on small related tasks that I can take in prior to my formal application for the GSoC project? I think committing small patches would be a great starting point to getting familiar with the Genode codebase.</div></div><div><br></div><div>Best Regards,</div><div><br></div><div>Zhongze Liu.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-01 19:37 GMT+08:00 Norman Feske <span dir="ltr"><<a href="mailto:norman.feske@...1..." target="_blank">norman.feske@...1...</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Sky Liu,<br>
<br>
thank you for your interest in Genode!<br>
<span class=""><br>
> I'm a college student majoring Information Security in HUST, and I'm<br>
> interested in genode's GSoC project on microkernelizaing the Linux<br>
> kernel. I've been quite interested in microkernel OSs and<br>
> virtualization, with limited experiences working on xen and the linux<br>
> kernel. and have been in the MINIX community for a short time, so I was<br>
> attracted by this challenge at the first sight.<br>
><br>
> However, I'm still new to the genode project. So I'll appreciate it if I<br>
> could get from you some suggestions on where to get started. :)<br>
<br>
</span>The best way to start exploring Genode is the "Genode Foundations" book,<br>
which you can download here:<br>
<br>
<a href="http://genode.org/documentation/genode-foundations-16-05.pdf" rel="noreferrer" target="_blank">http://genode.org/<wbr>documentation/genode-<wbr>foundations-16-05.pdf</a><br>
<br>
I recommend you to at follow the getting-started section, and skim over<br>
the Chapter 3 (Architecture) and Section 4.7 (Component compositions) to<br>
get a tangible feeling for Genode.<br>
<br>
To practically tackle the "microkernelization of Linux", there are<br>
actually two approaches. (1) The first approach is to enable Genode to<br>
access devices of the Linux system you are working on. This is<br>
convenient, but it bears the risk that a device driver (running in a<br>
Genode component) may interfere with the Linux kernel, crashing the<br>
system. The other approach (2) is booting a custom-made Linux system +<br>
Genode's core as init process in Qemu. The latter approach would be<br>
equivalent to how we work with the various microkernels.<br>
<br>
Depending on your interests, you may quickly dive in into the actual<br>
Genode code (1) or work on a custom run environment for Linux-based<br>
Genode system (2) first.<br>
<br>
Regarding the actual topic, the overall challenge is allowing Genode's<br>
device drivers access to the hardware that is normally accessed by the<br>
Linux kernel only. From Linux' point of view, Genode appears as a<br>
user-level device driver. So one piece of the puzzle is to gain a good<br>
understanding of Linux' user-level device-driver support. From Genode's<br>
perspective, device hardware is accessed through the IO_MEM, IO_PORT,<br>
and IRQ services of Genode's core component. So in principle, the topic<br>
comes down to implementing these services for the 'base-linux' version<br>
of core by using Linux' interfaces for user-level device drivers.<br>
<br>
There are several stages:<br>
<br>
1. By implementing the IO_PORT service, Genode components can interact<br>
with simple port-I/O-devices such as the PIT timer. The<br>
implementation should by straight-forward: When running core at<br>
I/O privilege level (IOPL) 3, core can execute the regular<br>
'inb', 'outb', etc. instructions. A simple test component could<br>
request a Genode IO_PORT session for, let's say, the PIT, program<br>
the PIT as a running counter, and repeatedly read the current<br>
counter value.<br>
<br>
2. Non-trivial devices need access to memory-mapped I/O registers.<br>
Core's IO_MEM service makes such registers available to its<br>
clients as a dataspace (the concept is explained in the book).<br>
On Linux, dataspaces are represented as memory-mapped files, passed<br>
from core to the driver component by passing a file descriptor, and<br>
attached to the driver's address space via 'mmap'. Consequently,<br>
the problem comes down to core obtaining a file descriptor for<br>
a given physical address region. Here the challenge is to find<br>
a suitable Linux kernel mechanism that hands out portions of<br>
physical memory as a file descriptor.<br>
<br>
With the principle support for memory-mapped I/O and port I/O<br>
in place, it should be possible to run the VESA framebuffer driver.<br>
<br>
3. Most drivers use device interrupts. To use those drivers, core's<br>
IRQ service needs to be implemented. Again, this calls for an<br>
investigation of Linux' user-level device driver support.<br>
<br>
4. Direct memory access. Many drivers use DMA to let the device<br>
write directly into memory. For this to work, the driver must<br>
supply the targeted memory address to the device. On systems<br>
without IOMMU, this is the physical bus address. In order to<br>
use DMA on Genode/Linux, DMA buffers need to be allocated as<br>
contiguous physical memory and their physical addresses must<br>
become known to the user-level driver component. In systems with<br>
IOMMU, the device-physical addresses a virtualized. So there is<br>
more freedom. But the details ultimately depends on the Linux<br>
handling of IOMMUs.<br>
<br>
5. In Genode, PCI devices are managed by the so-called platform<br>
driver. When a regular device driver needs access to a certain<br>
device, it does not use core's IO_MEM, IO_PORT, and IRQ services<br>
directly but it requests a platform session. A platform session is<br>
like a virtual bus where one or multiple devices are present,<br>
depending on the platform driver's policy. The platform session<br>
makes the device resources of those devices available to the<br>
client (the device driver). Under the hood, the platform driver<br>
opens IO_MEM/IO_PORT/IRQ sessions at core.<br>
<br>
In order to use Genode's existing arsenal of device drivers on<br>
Linux, we need either a platform-driver version specifically adapted<br>
for Linux (when re-using the Linux PCI driver), or investigate a way<br>
to use our regular platform driver (including the PCI driver)<br>
directly (this would be pretty cool!).<br>
<br>
I hope that the level of detail does not frighten you. We certainly<br>
don't expect you to complete all these stages. E.g., if completing stage<br>
1 to 3, there would already be demonstratable results. Stage 4 certainly<br>
requires an investigation into the ways about the interplay of the IOMMU<br>
handling of the kernel with user-level device drivers. Stage 5 also has<br>
a atrong design aspect to it.<br>
<br>
It goes without saying that we won't leave you on your own. :-)<br>
<br>
Cheers<br>
Norman<br>
<br>
--<br>
Dr.-Ing. Norman Feske<br>
Genode Labs<br>
<br>
<a href="http://www.genode-labs.com" rel="noreferrer" target="_blank">http://www.genode-labs.com</a> · <a href="http://genode.org" rel="noreferrer" target="_blank">http://genode.org</a><br>
<br>
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden<br>
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth<br>
<br>
------------------------------<wbr>------------------------------<wbr>------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, SlashDot.org! <a href="http://sdm.link/slashdot" rel="noreferrer" target="_blank">http://sdm.link/slashdot</a><br>
______________________________<wbr>_________________<br>
genode-main mailing list<br>
<a href="mailto:genode-main@lists.sourceforge.net">genode-main@...172...<wbr>net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/genode-main" rel="noreferrer" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/genode-main</a><br>
</blockquote></div><br></div>