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