Hybrid (micro)kernels

By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), September 4, 2006 9:25 am
Room: Moderated Discussions
Paul Elliott (pelliott@io.com) on 9/3/06 wrote:
---------------------------
>mas (mas769@hotmail.com) on 5/15/06 wrote:
>---------------------------
>>Don't know if you saw Tanenbaum's latest defence of microkernels but here it is if not.
>>
>>http://www.cs.vu.nl/~ast/reliable-os/
>>via
>>http://developers.slashdot.org/developers/06/05/15/1637206.shtml
>>
>I think that Prof. Tanenbaum's response to Mr. Torvalds
>on the question of microkernels should be examined in
>detail. The following is from:
>http://www.cs.vu.nl/~ast/reliable-os/

This is going to fill up David and Deans database :).

I'll answer bits I know about and ignore the rest if you don't mind...


>I really do not understand this. Why are Mr. Torvalds arguments
>not germane? Why is the following from Mr. Torvalds not germane?

Probably Tanenbaum hasn't read the discussion here.

>Professor Tanenbaum continues:
>
>
>TB> Besides, most of the user-space components are drivers, and they have
>TB> very straightforward interactions with the servers. All character
>TB> device drivers obey pretty much the same protocol (they read and write
>TB> byte streams) and all block device drivers obey pretty much the same
>TB> protocol (they read and write blocks). The number of user-space
>TB> servers is fairly small: a file server, a process server, a network
>TB> server, a reincarnation server, and a data store, and a few more. Each
>TB> has a well-defined job to do and a well-defined interaction with the
>TB> rest of the system. The data store, for example, provides a
>TB> publish/subscribe service to allow a loose coupling between servers
>TB> when that is useful. The number of servers is not likely to grow very
>TB> much in the future. The complexity is quite manageable. This is not
>TB> speculation. We have already implemented the system, after all. Go
>TB> install MINIX 3 and examine the code yourself.
>TB>
>
>Is all of the above correct?

The number of servers in any Microkernel I know of it not that large, and there is no reason to make it very large. I'm not sure thatthat the interfaces between them can be made simple and well defined. But I haven't read MINIX 3, he may have managed to do this.

>TB> Linus also made the point that shared data structures are a good
>TB> idea. Here we disagree. If you ever took a course on operating
>TB> systems, you no doubt remember how much time in the course and space
>TB> in the textbook was devoted to mutual exclusion and synchronization of
>TB> cooperating processes. When two or more processes can access the same
>TB> data structures, you have to be very, very careful not to hang
>TB> yourself. It is exceedingly hard to get this right, even with
>TB> semaphores, monitors, mutexes, and all that good stuff.
>TB>
>TB> My view is that you want to avoid shared data structures as much as
>TB> possible. Systems should be composed of smallish modules that
>TB> completely hide their internal data structures from everyone
>TB> else. They should have well-defined 'thin' interfaces that other
>TB> modules can call to get work done. That's what object-oriented
>TB> programming is all about--hiding information--not sharing it. I think
>TB> that hiding information (a la Dave Parnas) is a good idea. It means
>TB> you can change the data structures, algorithms, and design of any
>TB> module at will without affecting system correctness, as long as you
>TB> keep the interface unchanged. Every course on software engineering
>TB> teaches this. In effect, Linus is saying the past 20 years of work on
>TB> object-oriented programming is misguided. I don't buy that.
>TB>
>
>Prof. Tanenbaum seems to be saying that data hiding (encapsulation)
>prevents race conditions.

No he isn't. You've missed the point entirely here.

What he is saying is that if you design a set of modules/objects then within those modules you can decide on the mechanism of synchronisation. The only thing you reveal to the outside world is the function call interface. This is how synchronisation problems are usually handled in userspace, it is really modular programming not OO. Take malloc as an example, there are many different libraries for malloc/free. The function calls all work the same way, but they implement very different multi-threaded locking mechanism internally. The user of the malloc service need not know how it works.

Linus would probably argue that his kernel does exactly the same thing, just that it doesn't put the various modules into separate processes.

In your example with "Evil_struct" below illustrates the issue. Lets say that the implementor who has used a function call interface decides to change the locking mechanism inside his code. This is easy, he just does it maintaining the current function call interface. The implementor who has multiple different parts of the code accessing the same struct has a much more difficult time of it.

The flip side is that if the data structure is shared then it can be accessed in many ways, ways the designer possibly never thought of. This would require extra functions to be written in the more formal modular design.


>BUT ENCAPSULATION BY ITSELF DID NOT FIX THE RACE CONDITIONS.

Tut tut, no shouting when discussing kernels. This isn't a discussion about IA64 yer know :)

>In the microkernel design it is not data hiding that prevents race
>conditions, but rather the single threaded handling of an object's
>methods, so that each method runs to completion without being
>interrupted by another. This would be equivalent to acquiring a
>resource lock for the entire time that any method runs. This is a
>heavy handed one size fits all approach, as the resource lock may only
>be need for a short section of code to stop race conditions.

No, a microkernel need not take that approach. Many approaches can be taken inside one particular server and are. Between servers whatever systems protocols can be designed for can be implemented. It seems that quite complex protocols are necessary though.

>But single threaded handling of messages is NOT part of the Object
>Oriented paradigm!

No, nobody said it was.

>Therefore
>Mr. Torvalds cannot be accused of thought crimes against the object
>oriented ideology.

Oh yes he can be, but I don't think he minds :)

> It is true that Linux is coded in C but that does
>not prevent people from thinking about issues in a OO way, and it does
>not prevent OO implementation methods, coded by hand, from being used
>where appropriate.

It can, like many large C programs sometimes it does and often it doesn't. An attempt is made to do what is appropriate to the task.


>TB> Once you have decided to have each module keep its grubby little paws
>TB> off other modules' data structures, the next logical step is to put
>TB> each one in a different address space to have the MMU hardware enforce
>TB> this rule. When applied to an operating system, you get a microkernel
>TB> and a collection of user-mode processes communicating using messages
>TB> and well-defined interfaces and protocols. Makes for a much cleaner
>TB> and more maintainable design. Naturally, Linus reasons from his
>TB> experience with a monolithic kernel and has arguably been less
>TB> involved in microkernels or distributed systems. My own experience is
>TB> based on designing, implementing, and releasing multiple such
>TB> operating systems myself. This gives us different perspectives about
>TB> what is hard and what is not.
>TB>
>
>Is it not true that all the run time overhead of using the MMU to
>enfore this rule, could have been avoided by doing the checking at
>design-compile-link time? Does this not make Mr. Torvalds' idea of a
>OS compiling, constraint checking, computer language look good?

Mr. Torvald's idea. Crikey it's good been famous :) read the thread again and see who mentioned it first. Anyway, it's not an original idea, people have suggested it before.

>Mr. Torvalds does not need checkers, he has got hundreds of volunteer
>eyeballs looking at his code. The person who needs checking is the
>academic who is trying to get a research OS off the ground. Why don't
>the academics work on such a compiler, instead of pouring more effort
>into the rat hole of microkernels?
>
>Is it not true that in order to make such checking easy, the
>microkernel advocates force us to use an "event loop" style of
>programming instead of a more natural threaded aproach? Is this not
>what Mr. Torvalds is complaining about, rather than the red-herring of
>encapsulation?
>
>If the "thought experiment" mentioned above were optimized, would it
>not provide a way to use the MMU to do address space checking (if that
>were needed) without forcing us into a convoluted "event-loop" style
>of programming that breaks your algorithm into little pieces?

I don't understand this argument. If you use shared data structures then the accessing process must be able to modify them, this in itself if enough to cause trouble elsewhere when they're accessed again. So the MMU doesn't save you from very much in this instance.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Hybrid (micro)kernelsTzvetan Mikov2006/05/08 04:41 PM
  Hybrid (micro)kernelsS. Rao2006/05/08 06:14 PM
  Hybrid (micro)kernelsBill Todd2006/05/08 06:16 PM
    Hybrid (micro)kernelsTzvetan Mikov2006/05/08 07:21 PM
      Hybrid (micro)kernelsnick2006/05/08 07:50 PM
      Hybrid (micro)kernelsBill Todd2006/05/09 01:26 AM
        There aren't enough words...Rob Thorpe2006/05/09 02:39 AM
          There aren't enough words...Tzvetan Mikov2006/05/09 03:10 PM
            There aren't enough words...Rob Thorpe2006/05/15 12:25 AM
        Hybrid (micro)kernelsTzvetan Mikov2006/05/09 11:17 AM
          Hybrid (micro)kernelsBill Todd2006/05/09 04:05 PM
  Hybrid (micro)kernelsrwessel2006/05/08 11:23 PM
    Hybrid kernel, not NTRichard Urich2006/05/09 06:03 AM
      Hybrid kernel, not NT_Arthur2006/05/09 07:06 AM
        Hybrid kernel, not NTRob Thorpe2006/05/09 07:40 AM
          Hybrid kernel, not NT_Arthur2006/05/09 08:30 AM
            Hybrid kernel, not NTRob Thorpe2006/05/09 09:07 AM
              Hybrid kernel, not NT_Arthur2006/05/09 09:36 AM
                Linux vs MacOSX peformance, debunked_Arthur2006/05/18 07:30 AM
                  Linux vs MacOSX peformance, debunkedRob Thorpe2006/05/18 08:19 AM
                    Linux vs MacOSX peformance, debunkedAnonymous2006/05/18 12:31 PM
        Hybrid kernel, not NTLinus Torvalds2006/05/09 08:16 AM
          Hybrid kernel, not NTAndi Kleen2006/05/09 02:32 PM
            Hybrid kernel, not NTmyself2006/05/09 03:24 PM
              Hybrid kernel, not NTmyself2006/05/09 03:41 PM
              Hybrid kernel, not NTBrendan2006/05/09 05:26 PM
                Hybrid kernel, not NTLinus Torvalds2006/05/09 08:06 PM
                  Hybrid kernel, not NTBrendan2006/05/13 01:35 AM
                    Hybrid kernel, not NTnick2006/05/13 04:40 AM
                      Hybrid kernel, not NTBrendan2006/05/13 09:48 AM
                        Hybrid kernel, not NTnick2006/05/13 07:41 PM
                          Hybrid kernel, not NTBrendan2006/05/13 09:51 PM
                            Hybrid kernel, not NTnick2006/05/14 05:57 PM
                              Hybrid kernel, not NTBrendan2006/05/14 10:40 PM
                                Hybrid kernel, not NTnick2006/05/14 11:46 PM
                                  Hybrid kernel, not NTBrendan2006/05/15 04:00 AM
                                    Hybrid kernel, not NTrwessel2006/05/15 07:21 AM
                                      Hybrid kernel, not NTBrendan2006/05/15 08:55 AM
                                        Hybrid kernel, not NTLinus Torvalds2006/05/15 09:49 AM
                                          Hybrid kernel, not NTnick2006/05/15 04:41 PM
                                          Hybrid kernel, not NTtony roth2008/01/31 02:20 PM
                                    Hybrid kernel, not NTnick2006/05/15 06:33 PM
                                      Hybrid kernel, not NTBrendan2006/05/16 01:39 AM
                                        Hybrid kernel, not NTnick2006/05/16 02:53 AM
                                          Hybrid kernel, not NTBrendan2006/05/16 05:37 AM
                  Hybrid kernel, not NTAnonymous2008/05/01 10:31 PM
                    Following the structure of the treeMichael S2008/05/02 04:19 AM
                      Following the structure of the treeDean Kent2008/05/02 05:31 AM
                        Following the structure of the treeMichael S2008/05/02 06:02 AM
                        Following the structure of the treeDavid W. Hess2008/05/02 06:48 AM
                          Following the structure of the treeDean Kent2008/05/02 09:14 AM
                            Following the structure of the treeDavid W. Hess2008/05/02 10:05 AM
                              LOL!Dean Kent2008/05/02 10:33 AM
                              Following the structure of the treeanonymous2008/05/02 03:04 PM
                                Following the structure of the treeDean Kent2008/05/02 07:52 PM
                                Following the structure of the treeFoo_2008/05/03 02:01 AM
                                  Following the structure of the treeDavid W. Hess2008/05/03 06:54 AM
                                    Following the structure of the treeDean Kent2008/05/03 10:06 AM
                                      Following the structure of the treeFoo_2008/05/04 01:06 AM
                                        Following the structure of the treeMichael S2008/05/04 01:22 AM
            Hybrid kernel, not NTLinus Torvalds2006/05/09 05:19 PM
              Microkernel Vs Monolithic KernelKernel_Protector2006/05/09 09:41 PM
                Microkernel Vs Monolithic KernelDavid Kanter2006/05/09 10:30 PM
                  Sigh, Stand back, its slashdotting time. (NT)Anonymous2006/05/09 10:44 PM
                  Microkernel Vs Monolithic Kernelblah2006/05/12 08:58 PM
                  Microkernel Vs Monolithic KernelRob Thorpe2006/05/15 01:41 AM
          Hybrid kernel, not NTAnalGuy2006/05/16 03:10 AM
            Theory versus practiceDavid Kanter2006/05/16 12:55 PM
              Distributed algorithmsRob Thorpe2006/05/17 12:53 AM
              Theory versus practiceHoward Chu2006/05/17 02:54 AM
                Theory versus practiceJS2006/05/17 04:29 AM
          Play online poker, blackjack !!! Gamezonex2007/08/16 01:49 PM
  Hybrid (micro)kernelsphilt2006/05/14 09:15 PM
    Hybrid (micro)kernelsLinus Torvalds2006/05/15 08:20 AM
      Hybrid (micro)kernelsLinus Torvalds2006/05/15 11:56 AM
        Hybrid (micro)kernelsRob Thorpe2006/05/16 01:22 AM
          Hybrid (micro)kernelsrwessel2006/05/16 11:23 AM
            Hybrid (micro)kernelsRob Thorpe2006/05/17 12:43 AM
              Hybrid (micro)kernelsrwessel2006/05/17 01:33 AM
                Hybrid (micro)kernelsRob Thorpe2006/05/19 07:51 AM
                  Hybrid (micro)kernelsrwessel2006/05/19 12:27 PM
      Hybrid (micro)kernelstechIperson2006/05/15 01:25 PM
      Hybrid (micro)kernelsmas2006/05/15 05:17 PM
        Hybrid (micro)kernelsLinus Torvalds2006/05/15 05:39 PM
          Hybrid (micro)kernelsColonel Kernel2006/05/15 09:17 PM
            Hybrid (micro)kernelsWink Saville2006/05/15 10:31 PM
              Hybrid (micro)kernelsLinus Torvalds2006/05/16 10:08 AM
                Hybrid (micro)kernelsWink Saville2006/05/16 09:55 PM
          Hybrid (micro)kernelsrwessel2006/05/16 11:31 AM
            Hybrid (micro)kernelsLinus Torvalds2006/05/16 12:00 PM
        Hybrid (micro)kernelsBrendan2006/05/16 01:36 AM
        Hybrid (micro)kernelsPaul Elliott2006/09/03 08:44 AM
          Hybrid (micro)kernelsRob Thorpe2006/09/04 09:25 AM
      Hybrid (micro)kernelsphilt2006/05/16 12:55 AM
        Hybrid (micro)kernelspgerassi2007/08/16 07:41 PM
  Another questionable entry on Wikipedia?Chung Leong2006/05/18 10:33 AM
  Hybrid (micro)kernelsisrael2006/05/20 04:25 AM
    Hybrid (micro)kernelsRob Thorpe2006/05/22 08:35 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell purple?