Page 1 of 3

Microkernels

Posted: Thu Dec 16, 2004 12:59 pm
by Balroj
Hi everyone,

I've a few questions about message passing on microkernels.I supose between modules and kernel messages i pass are those i design, but does the compiler support some basic messages or have to code it?

I mean, in linux for example when whe do a killall -HUP we pass a mesage to daemon for reset. or some user app we can pass messages, is this support to "understand" and recieve messages on the compiler or in the app?

Thanks.

Re:Microkernels

Posted: Thu Dec 16, 2004 3:18 pm
by Candy
When you OSdev you do not have anything but a big space called "address space", filled with wastelands, potholes and quicksand (equivalent to free memory, nonexistant memory and device memory). You do not get ANYTHING for free. There are a few things you can pretty much assume nowadays (and I know I'm going to be attacked on this later on), there is something called IO space in which some devices are present, there is a PS/2 keyboard (lying already... I don't have a PS2 keyboard), you can use a mouse (of sorts), there is textual video memory from 0xB8000 and on, and your own code (512 bytes) is present at 0x7C00.

That's all you have.

Message passing requires memory allocation and freeing, and potentially protection (otherwise, what's the use of messages?). These all require that you A. know what is in the area around you, B. control it.

The idea is to start by finding out where the wastelands go, then placing fences marking squares you can use (or using some method of deciding to place fences upon function call), and using the area between fences. Define some area as a program (load it there), then mark it as execute-only, define some other area as driver module and do the same, then define a third area where some OS feature can place messages or where it stores the address of its message passer. The two programs can then use the information there to pass messages.

That's a very basic and very simple idea of how it works.

Re:Microkernels

Posted: Sun Dec 19, 2004 5:33 am
by Balroj
Thanks candy for answer me.

But exactly what is function of message passing? or in other way why message passin and not api call?

Re:Microkernels

Posted: Sun Dec 19, 2004 6:04 am
by AR
Messaging allows asyncronus operation, when you have 1 CPU only 1 process(or thread) runs at a time, messaging will allow you to queue messages for other programs so when it's their turn to run they can process the queue. Messaging isn't used between libraries, since a library doesn't run directly, it can only be used between processes. APIs are only calls from a process to a library or the Kernel.

In your "killall" example, it would actually be signaling, not messaging. A signal is like a software interrupt, if the program doesn't declare a handler, the default action is performed [Abort/Ignore/Special], SIGKILL interrupts the program and forces it to close, it is performed by the Kernel and can't be handled.

Wiki Entries:
http://www.osdev.org/osfaq2/index.php/Message%20Passing
http://www.osdev.org/osfaq2/index.php/Signals

Re:Microkernels

Posted: Sun Dec 19, 2004 2:24 pm
by Balroj
Hi ar,

first of all thanks for answer me.
messaging will allow you to queue messages for other programs so when it's their turn to run they can process the queue
Ok. That's sounds like pipe on UNIX like OS, so my deamos will use something like pipes? What's the diference between pipes and message passing?

In every web i search message passing is something basically in every microkernel, but are them simples pipes or something more?

thanks for all

and sorry for this silly questions.

Re:Microkernels

Posted: Sun Dec 19, 2004 8:33 pm
by Brendan
Hi,
Balroj wrote: Ok. That's sounds like pipe on UNIX like OS, so my deamos will use something like pipes? What's the diference between pipes and message passing?

In every web i search message passing is something basically in every microkernel, but are them simples pipes or something more?
Pipes transfer a stream of bytes, while messaging sends/receives whole messages only. Basically, pipes are like telnet while messaging is like email :-)

The pipes normally connect one process to another, while a message queue will/can accept messages from anywhere at the same time. With pipes (I'm guessing) the process figures out who is connected on the other end of the pipe when the pipe is created, while with messaging each message is (typically) delivered with an identifier saying who sent it.

For a microkernel, you generally want to unblock a thread (give it some CPU time) when it has received a complete "transaction" that it can process. With pipes there's no sane way to tell when one "transaction" ends and another starts, which makes it impossible for the kernel to figure out when it needs CPU time. AFAIK on *nix a process could receive CPU time every time a single byte is received, which is IMHO stupid when often this byte is only stuffed into a second buffer (it's fine if you're using a crappy round robin scheduler as per the original 1960's Unix, but most modern OS's have progressed since then).


Cheers,

Brendan

Re:Microkernels

Posted: Mon Dec 20, 2004 5:14 am
by mpp.eox3
Balroj wrote: In every web i search message passing is something basically in every microkernel, but are them simples pipes or something more?
IPC in a microkernel shouldn't be "something more", instead "something less"; something very simple that can be implemented fast. In L4 for example, only synchronous messaging is allowed - this avoids the need of a buffer where the message gets queued [This relates to part 3 ("...unblock a thread...") of Brendans post above].
Why this is so bad, is that the queue will potentially blow up when a malicious user keeps sending stuff asynchronically.
With synchronous message passing however, a malicious thread will only harm itself (wasting its own execution time).

I just happened to listen to some IPC topic in our today's course, the slides where very interesting. (Also the speaker told some interesting L4 internal details :).
The slides are located here, if you're interested:
http://i30www.ira.uka.de/teaching/coursedocuments/109/Thread%20switch%20and%20IPC.pdf

Regarding your question about compiler support, I think you might take a look at this L4 IDL stuff. But I think this is not very important in the beginning, because it's just some optimization. I'd first concentrate on getting some IPC to work at all. To make things easy you could manually fit function parameters into your message passing registers, e.g. something like:

Code: Select all

unsigned function(unsigned param1, unsigned param2, unsigned param3)
{
  unsigned ret;
  __asm {
    mov ebp, param1
    mov esi, param2
    mov edi, param3
    ...syscall to ipc... oh and don't forget to put the receiver threadID somewhere..
    mov ret, eax
  }
  return ret;
}
This is at least my current plan to try out soon when I've got some time... but I think I'll do a simple 3d engine completely in software first :)

73/m++

Re:Microkernels

Posted: Mon Dec 20, 2004 5:37 am
by AR
Why this is so bad, is that the queue will potentially blow up when a malicious user keeps sending stuff asynchronically.
There is a very simple way to counter this though, if a process tries to message another process when its queue is full then block the sender until the queue has enough space to put in another message.

Re:Microkernels

Posted: Mon Dec 20, 2004 6:12 am
by distantvoices
misbehaving processes/threads ...

It is indeed as AR states, you block a sender, if the queue is full and have it resend the message as soon as place is available.

I should consider implementing this.

Basically the message passing mechanism and the task switcher are tightly coupled in a micro kernel for any sent message may cause a task switch - the receiving process woken up, preempting some other process.

Taking this in to consideration, the most important thing for you to build in order to have a sound base for your os is a stable task switching and Task Control Block Manager and a Message Passer - and the low level stuff: Interrupts, GDT, IDT stuff, but that's covered otherwhere.

Your os will then look like this ... approx. me cheats often and puts system calls directly into the micro kernel: Semaphores, Signals, events.

Code: Select all

     Shell   |   Browser   |    Game    |     Notepad   -> Userland
     --------------------------------------------
      FS Srv    |    Process Srv    |    GUI Srv    |   TCP/IP  -> SErvices
     --------------------------------------------
      Mouse|Keyboard|Memory|ramdisk|rtl8139|IDE  -> drivers
     --------------------------------------------
      Kernel (IPC, Interrupt abstraction, Task Switcher)

From the above structure you can easily deduce that the easiest approach to design the kernel is the event driven approach. Second, mark that the whole memory of the computer belongs to you (except of reserved portions of course) - with paging you insert an additional level of abstraction to ease the management of dealt out memory - with the concept of the *virtual address space*

Hope this clears some things a bit.

Re:Microkernels

Posted: Mon Dec 20, 2004 8:11 am
by Balroj
Hi, thanks for the answers

Anyone knows a microkernel, a simple and basic one , to take a look?

Thanks for all

Re:Microkernels

Posted: Mon Dec 20, 2004 11:27 am
by Candy
I would suggest Minix, as it's not that big and very much documented (as in, it's got a load of docs, but I don't know whether they are good).

Re:Microkernels

Posted: Mon Dec 20, 2004 11:31 am
by Balroj
minix is a microkernel? :-[

Any of the forum developer has a microkernel? ( I tried clicker32 but it's big for me )

Re:Microkernels

Posted: Mon Dec 20, 2004 11:36 am
by pini
I'm making my own microkernel : Virtuose

Minix is a microkernel.
It was written by Andrew Tannenbaum for studying purpose. Tannenbaum & Torvalds violently opposed their minds : The first thought microkernel was the best design and the second thought it was monolithic kernel the best.
So says the legend.

Re:Microkernels

Posted: Mon Dec 20, 2004 11:44 am
by Balroj
pini, os there anywhere i can download your kernel source?

Re:Microkernels

Posted: Mon Dec 20, 2004 12:52 pm
by pini
The source will (hopefully) be uploaded the 24th.
Check this : http://virtuose.mondelibre.org

The website is in french.