Hello Althaf,
welcome to the mailing list! :-)
Answers to my question does lie in /base-host directory and checking out already implemented base-xxx.However, before i dive into them if you could explain the underlying mechanism that genode expect from a new/fresh dedicated kernel meant to use genode it would help understand the /base-{host,linux,et al} better.
This is a very good question - but also a very tough one to answer in general. The answer depends on the goal you are pursuing with the kernel. For example, some of Genode's base platforms implement the complete Genode API functionality-wise, but do not provide kernel-protected capabilites that are needed to achieve the high security as suggested by the Genode concept. But these platforms are still fine for many use cases where security is not the primary concern. The 'base-linux' platform is an extreme case because it actually does not provide isolation between Genode's protection domains at all (dataspaces are just files at '/tmp/' and threads communicate via sockets w/o any access control). Still, this platform is extremely valuable to us as development platform. The 'base-okl4' platform does provide a certain degree of protection via L4 mechanisms but still lacks a rigid way to constrain the inter-process communication. The only base platforms fully supporting Genode's security model at the kernel level are NOVA and Fiasco.OC.
Given that I do not know much about your actual goal, I am afraid that my answer might be either too abstract to be useful or to much tied to a particular kernel interface.
Let's first look at Genode from a high level by just examining its API. To implement the API, the kernel has to provide mechanisms for implementing the following functionality on top:
:The creation, destruction, and remote manipulation of protection domains:
Strictly speaking, it is not entirely clear that protection domains are needed in all cases. I could imagine a version of Genode that executes all processes within one unprotected address space, i.e., physical memory - similar to how uCLinux works. Of course, such a platform would not be able to provide protection and isolation between processes but for embedded applications that consist of trusted code only, this constuct might still be useful.
:Support for establishing shared memory between protection domains:
:A way to execute multiple threads in a protection domain, scheduled in a preemptive (non-cooperative) way:
Again, this is not a definitive statement. A specialized platform might be able to function with merely cooperative multi-threading. In Genode, there is no inherent dependency on preemtive scheduling. However, applications may expect this semantics from Genode's 'Thread' API.
:Letting threads of different address spaces communicate in an RPC-like fashion:
The mechanism for RPC-like communication could be synchronous IPC as provided by L4 kernels but it does not need to be. For example, some years ago, Genode's RPC API was ported to Xen, using shared memory and Xen's event channels only.
:Letting threads of different address space communicate via asynchnonous notifications:
Those notifications do not need to carry payload. Raw signal semantics are fine.
:Lock-based thread synchronization:
One important semantic detail is that once a thread blocks, the blocking must be cancelable by another thread. If you like, we can go into detail in a follow-up posting.
:Access to I/O resources such as interrupts and memory-mapped registers:
You see my struggle with giving definitive statements here? This is because I believe that there is no single "right" way to go.
Let's also look from the other way, starting with concrete requirements. When we wanted to run Genode on FPGA softcores, we decided to go for a custom kernel design instead of adapting one of Genode's already supported base platforms. Our goal was to find the simplest kernel interface possible given that our use case does not require capability-based security, and the hardware platform consists of a single core with a software-loaded TLB. The resulting kernel interface may serve you as inspiration. You can find it here:
http://genode.svn.sourceforge.net/viewvc/genode/trunk/base-mb/include/kernel...
Like, threads, shared memory, sockets, paging, MMU support etc.It would be excellent , if we have an article in [1] explaining porting to hypothetical kernel.
I would appreciate you providing us with some more details about the goals you want to address with your custom kernel. E.g., Is it meant to be as simple as possible? Which degree of security do you want to achieve? Should your kernel scale to many cores? Which hardware architectures do you have in mind?
Best regards Norman