Page 2 of 3
Re:Microkernels
Posted: Mon Dec 20, 2004 2:41 pm
by distantvoices
@balroj: you can take a look at mine:
www.distantvoices.org
just follow the link "BlueIllusionOS" then proceed to the downloads section.
In my kernel, mosta variables and functions are in german. you've been warned. *winkwink*
@pini: Hehe, one more micro kernel maker. Thats good. How's the going with the message passing? According to your site, it develops fine. (no problem with the french)
Re:Microkernels
Posted: Mon Dec 20, 2004 3:30 pm
by FlashBurn
I also have a question to microkernel message passing! What is better, a fixed size msg or a dynamic sized msg?
I will take the BEOS approach and every thread can create a msg port and there it has to tell how much msgs the port can take.
Also when thread A sends a msg to thread B thread B gets the rest of the time of thread A. What do you think of this?
Re:Microkernels
Posted: Mon Dec 20, 2004 8:36 pm
by Brendan
Hi,
FlashBurn wrote:
I also have a question to microkernel message passing! What is better, a fixed size msg or a dynamic sized msg?
I will take the BEOS approach and every thread can create a msg port and there it has to tell how much msgs the port can take.
There's a pile of different ways to implement messaging, with different advantages/disadvantages for each. Which is better depends a lot on how the messaging is going to be used.
For example, on my OS applications send video data to the user interface code via messaging. This may be in the form of a script, ASCII TTY, UNICODE TTY or raw pixel data. For raw pixel data in 1024*768*32bpp format there's 3 MB of data. My messaging supports variable sized messages up to 32 MB and sends page table entries or page directory entries if the message is large (e.g. for a 32 MB message the kernel copies 32 bytes from one address space to the message queue, and then from the message queue to the receivers address space). I use message queues to avoid excessive thread switches, so a thread could send 100 messages to 100 message queues without causing any (slow) thread switches.
To do the same thing on L4 you'd need to break the 3 Mb of data up into 393216 seperate messages, and because L4's messaging causes 2 thread switches per message it would become far too slow to consider (even though L4 can send one little fixed size message faster than my OS ever will). This makes me wonder how you would send large amounts of data on L4 - you could store it in a file and try to send the file name instead, but it's messaging won't even handle a file name. Perhaps L4's kernel has a function to convert a file name into a unique integer that can be sent (like Windows)... IMHO variable length messages are much simpler in the end (even though the kernel's messaging code is more complex).
FlashBurn wrote:
Also when thread A sends a msg to thread B thread B gets the rest of the time of thread A. What do you think of this?
If you want a pre-emptive scheduler (or if you support multi-CPU computers), the thread that's receiving the message may be running. In this case passing messaging data in registers across the thread switch doesn't work so well - you'd need to block the sending thread until the receiving thread stops running. This can lead to dead-locks (2 or more threads waiting for each other indefinately).
It would also have an effect on the scheduler's thread priorities. If a low priority thread is receiving a series of messages from a high priority thread, then it will effectively behave as if it's a high priority thread.
Cheers,
Brendan
Re:Microkernels
Posted: Tue Dec 21, 2004 1:25 am
by Colonel Kernel
Balroj wrote:
minix is a microkernel? :-[
I've read a good chunk of Tanenbaum's book, and the interesting parts of the Minix source code. Although in spirit it looks like a microkernel, it's a pretty poor example of one IMO. I realize it's stripped down to keep things simple... or at least, it's supposed to be, except that it has these highly inappropriate layers and inefficiencies that simply don't make sense. Case in point -- the clock tick handler has its own dedicated task, which from an efficiency standpoint is kind of ridiculous. And since it's so slow, there are some kludges in the kernel itself to speed things up. So, even though there is a clock "task", it is compiled into the kernel and there is no real clean boundary to keep things modular (nor should there be in the case of the @#$)(* clock!! But for other things like the file system, the lack of modularity causes problems).
If you want to look at a less confused example of a microkernel, check out L4 or
QNX.
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.
FWIW, I disagree with both Tanenbaum and Torvalds.
To me, Minix is such a confused mess that it's no wonder Torvalds rejected that approach. Even Mach suffers from some of the same problems and accidental complexity. I think if there were a better example of a microkernel under discussion at the time, things might have turned out a lot differently.
BTW, here's a link to the
Tanenbaum-Torvalds debate.
Re:Microkernels
Posted: Tue Dec 21, 2004 1:37 am
by mpp.eox3
Brendan wrote:
To do the same thing on L4 you'd need to break the 3 Mb of data up into 393216 seperate messages, and because L4's
L4's IPC can handle up to 4Mb. (They call it "StringItem")
Re:Microkernels
Posted: Wed Dec 22, 2004 5:29 am
by Balroj
thanks pini and beyond infinity for your code
One thing, when you said L4 you refer to ring4?
Re:Microkernels
Posted: Wed Dec 22, 2004 6:33 am
by Pype.Clicker
Balroj wrote:
thanks pini and beyond infinity for your code
One thing, when you said L4 you refer to ring4?
No, there's no such thing. L4 is a microkernel implementation, which was indeed tiny, asm-oriented and rather efficient compared to other attempts.
Re:Microkernels
Posted: Wed Dec 22, 2004 7:20 am
by Balroj
thanks pype,
Are there some kind of guide or intruduction of how to structure or ways to implement IPC? Or as you said in other post it just depends to the OS designer?
Thanks
Re:Microkernels
Posted: Thu Dec 23, 2004 9:23 am
by Balroj
I mean when your said fixed sized msg, o dinamically sized msg. and more things about the IPC.
thanks.-
Re:Microkernels
Posted: Thu Dec 23, 2004 10:13 am
by pini
I'm using a dynamically sized message. The sender gives the size which must be less than one page (including message structure : sender PID, destination PID, message size).
The data is located directly after the message structure, so that everything fits in a memory page.
Re:Microkernels
Posted: Tue Jan 04, 2005 5:14 pm
by Balroj
Hello,
more questions:
keyboard, mouse, and others drivers in beyond' post schmatic are on the same ring as fs server? fs server comunication with flopy driver is via IPC? or via interrupts?
Re:Microkernels
Posted: Wed Jan 05, 2005 4:36 am
by distantvoices
I've put device drivers (kbd, mouse, floppy, etc) at ring0. It is your own decision where you put them.
You ofcourse need other means of IPC besides message passing. I propose a means to stream data between processes - some kind of intermediary buffer, which takes data and passes it forward to the receiver.
Stay safe.
Re:Microkernels
Posted: Thu Jan 06, 2005 5:45 am
by Balroj
something like sockets? pipes? o something different?
Re:Microkernels
Posted: Thu Jan 06, 2005 8:18 am
by Brendan
Hi,
beyond infinity wrote:
I've put device drivers (kbd, mouse, floppy, etc) at ring0. It is your own decision where you put them.
You ofcourse need other means of IPC besides message passing. I propose a means to stream data between processes - some kind of intermediary buffer, which takes data and passes it forward to the receiver.
Why?
There's nothing wrong with message passing to/from ring0 code if the device drivers have their own address space. If the device drivers are mapped into all address spaces, then use far calls or software interrupts instead of IPC (it'd be much faster).
Cheers,
Brendan
Re:Microkernels
Posted: Thu Jan 06, 2005 2:30 pm
by Balroj
There's nothing wrong with message passing to/from ring0 code if the device drivers have their own address space. If the device drivers are mapped into all address spaces, then use far calls or software interrupts instead of IPC (it'd be much faster).
I couldn't understand it very well, can you explain it a little bit? thanks and sorry.