Microkernels
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Microkernels
@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)
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)
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Microkernels
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?
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
Hi,
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).
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
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).
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).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?
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re:Microkernels
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).Balroj wrote: minix is a microkernel? :-[
If you want to look at a less confused example of a microkernel, check out L4 or QNX.
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.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.
BTW, here's a link to the Tanenbaum-Torvalds debate.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re:Microkernels
L4's IPC can handle up to 4Mb. (They call it "StringItem")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
Re:Microkernels
thanks pini and beyond infinity for your code
One thing, when you said L4 you refer to ring4?
One thing, when you said L4 you refer to ring4?
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Microkernels
No, there's no such thing. L4 is a microkernel implementation, which was indeed tiny, asm-oriented and rather efficient compared to other attempts.Balroj wrote: thanks pini and beyond infinity for your code
One thing, when you said L4 you refer to ring4?
Re:Microkernels
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
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
I mean when your said fixed sized msg, o dinamically sized msg. and more things about the IPC.
thanks.-
thanks.-
Re:Microkernels
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.
The data is located directly after the message structure, so that everything fits in a memory page.
Re:Microkernels
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?
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?
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Microkernels
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.
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.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Microkernels
Hi,
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
Why?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.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Microkernels
I couldn't understand it very well, can you explain it a little bit? thanks and sorry.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).