the Base API can be regarded as a "bottom layer specification" (its implementation is typically less than 10KLOC) of the whole system but there is no fixed base-internal interface. This gives each platform maximum flexibility about how the API is implemented. Given the vast differences of the mechanisms used, this flexibility is needed. E.g., by comparing the ways processes are created and address spaces are managed on Linux and L4, you will see that the respective base code has almost nothing in common. On Linux, 'rm_session()->attach()' is implemented locally by the calling process using mmap. In contrast, on L4, the same API function is an RPC to core, which, in turn, manipulates the address space on demand (using L4's map/unmap) when a page fault occurs.
Yes, i get the notion, actully at the moment i'm trying to understand base-linux. I must admit the source became much more clear after your explained the actual idea of why 'no solid bottom specification'. Another fact, i read a lot of code from various projects, genode code the most readable with well structured cpp and build setup.
topic "Microkernelizing Linux" described on our "Challenges" Wiki page? http://genode.org/community/wiki/Challenges
Yes infact.
Let me suggest two pointers that we stumbled upon when we brain-stormed this idea. First, we were pointed to Linux' "resource containers", which promise to allow the assignment of fine-grained resource constraints to individual processes. This looks like an interesting mechanism to support Genode's resource-trading concept. Secondly, we were made aware of the Capsicum project, which brings capability-based security to Linux.
Linux containers should be LXC project from IBM.?
Hello Althaf,
Let me suggest two pointers that we stumbled upon when we brain-stormed this idea. First, we were pointed to Linux' "resource containers", which promise to allow the assignment of fine-grained resource constraints to individual processes. This looks like an interesting mechanism to support Genode's resource-trading concept. Secondly, we were made aware of the Capsicum project, which brings capability-based security to Linux.
Linux containers should be LXC project from IBM.?
Some time ago, I stubled over the following article:
http://lwn.net/Articles/236038
admittedly, I do not know what came out of the described patch - I just kept the article in the back of my head. .-)
Cheers Norman
Some time ago, I stubled over the following article:
Yes, and lxc make use of these mechanisms to implement the resource container concept. As i read from linux Documentaton, it is called 'cgroups'.
Will this make genode a redundant implementation over linux? I See many things common at concept level in cgroups and genode.
- /althaf k backer/
Hi Althaf,
Yes, and lxc make use of these mechanisms to implement the resource container concept. As i read from linux Documentaton, it is called 'cgroups'.
Will this make genode a redundant implementation over linux? I See many things common at concept level in cgroups and genode.
it depends on your actual goal. If you are seeking a UNIX-like system with OS-level virtualization and a way to restrict resource usage on a per-process (or per process-group basis), the plain use of cgroups looks to me like a very good idea. Similarly, if you are seeking a UNIX-like system with support for expressive security policies, seLinux fits very well.
However, if you consider to take a step back from UNIX in the first place, alternative and far less complex approaches come into reach.
For example, even with cgroups, Linux needs a central authority (mostly in the form of an administrator) with a global view on the system to manage cgroups. The same for seLinux, where you need a central authority to administer the global seLinux policy. In fact, on Linux there is a bunch of those "global authorities" in the form of kernel services and daemons. In contrast, Genode largely alleviates the need for an authority with global knowledge. The system is composed of arbitrarily nested subsystems, each taking care of its local concerns only. It turns out that the resulting system is orders of magnitude less complex in terms of TCB complexity and at the same time more flexible as the complete OS can be virtualized at each node in the process hierarchy.
Genode was not created to improve Linux in the first place. Instead it poses an architectural *alternative* to UNIX. The Linux version exists solely for the pragmatic reason that it vastly accelerates development and testing.
That said, I think that the Linux version of Genode using cgroups (and capsicum?) as underlying mechanism could bring value to both Genode and Linux. For Genode, this base platform would become a feasible host for all those real-world applications where a low-complexity kernel is not the prime concern. For Linux, Genode could be an alternative to the GNU userland for applications that rely on the feature-rich Linux kernel but do not need (nor want) the complexity of GNU. E.g., Android and Chrome OS hardly anticipate the GNU userland. Both somehow try to cut back the complexity of their respective userland but come nowhere as close to the low complexity of Genode.
Finally, this would be cool project because it completely blurs the line between monolithic kernels and microkernels, putting the long-winded and heated discussions between both camps in an interesting perspective. ;-)
Best regards Norman
-
Althaf -
Norman Feske