OSDev.org

I'm extremely interested in replacing the kernel in my OS with L4::Pistachio primarily for it's speed. I'm still int he planning stages of this operation, and I have a few questions.

Firstly, from what I understand sigma0 is the first user-task, and on bootup it has all physical memory and IO ports mapped to it, and other tasks (or just the root task?) request memory from it. Also what is the purpose of sigma1 (a clone of sigma0?) and an example of when you would need it?

Secondly, a core concept in my OS is assigning names to processes so you can look up the PIDs of servers and the like. This was in the kernel in my previous microkernel, so I'll now have to implement it in a Process Server, which will also be in charge of associating processes with users and their permission levels (most likely this will be the root task in L4 terms). A core feature of this is knowing when a process terminates, the most obvious way is the process sends an message to the Process Server telling it to terminate. But, what if a process terminates it's own threads, or terminates due to an exception? Does L4 have a mechanism for capturing these events?

Thirdly, how do privilege and priority levels work? I understand that the root task begins as a privilege process, and it is the only privileged process there is?

Thanks in advance.

You'd have to wait for the programmer's manual to show up, I bet :).


JAL

berkus wrote:sigma0 is memory manager, it owns whole address space on startup and maps/grants it to processes requesting memory during runtime.

If I understand correctly, ANY thread can communicate with sigma0? So ANY thread can allocate as much memory at any physical address it wants? (Not so good when I'm trying to build an OS on top of the kernel that runs untrusted user code.)

So ultimately, my root task/process server should allocate all memory into itself, that way any thread trying to call sigma0 will return null and have to go through my process server instead? (Which makes me wonder, why can't my process server be sigma0 and remove a step.)

Also, I was compiling the user applications provided with L4Ka:Pistachio and noticed it's possible to write to the screen by directly accessing 0xB8000 without any prior system calls or IPC'ing with sigma0. Now I thought being a microkernel with memory protection, you would have to ask sigma0 to make the page containing the text buffer into the local address space, or is there an exception for the root task?

Can somebody please explain if I'm missing something?

Thanks.

berkus wrote:Afaik the reference root_server runs privileged (hence with all pages available to kernel mapped)? I didn't verify that though, kernel API and KIP was enough reading for me.

I received a response from the L4 mailing list that answered my question:

Since sigma0 is the pager of the roottask and since sigma0's pagefault handler simply hands out 1:1 virtual to physical mappings, this is to be expected.

And to answer the question about sigma0: That cleared things up a lot. Thanks for your help.

The only issue I'm having at the moment is that the latest L4Ka:Pistachio source off the Mercurial repository requires GCC 3.x to build, and I'm currently running GCC 4.4.1. So as I'm typing this I have GCC 3.4.6 building...

The source compiles fine under the later GCC, but I get endless runtime issues such as IPC failing and memory locations being mapped wrongly.

berkus wrote:

MessiahAndrw wrote:The only issue I'm having at the moment is that the latest L4Ka:Pistachio source off the Mercurial repository requires GCC 3.x to build, and I'm currently running GCC 4.4.1. So as I'm typing this I have GCC 3.4.6 building...

The source compiles fine under the later GCC, but I get endless runtime issues such as IPC failing and memory locations being mapped wrongly.

It's a major PITA with most of the research OSes from the ole good days. OSKit doesn't compile well with gcc above 2.95 iirc and it took me a good hacking session to make Flick at least compile with gcc4.

What license /is/ Oskit under? I wonder what people would think if a part of the OSDev community revived the project.....