Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!tut.cis.ohio-state.edu!cis.ohio-state.edu!terri_watson From: terri_watson@cis.ohio-state.edu Newsgroups: comp.org.usenix Subject: Re: W91 USENIX in retrospect Message-ID: Date: 4 Feb 91 20:14:19 GMT References: <26879@ucsd.Edu> <10404@muffin.cme.nist.gov> Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 47 In-reply-to: libes@cme.nist.gov's message of 4 Feb 91 16:41:15 GMT Well, I won't really summarize any papers, but I might encourage some discussion on the kernel panel session. I found it interesting and slightly entertaining. The main theme was micro vs. monolithic kernel design . what should be in the kernel? is it better to have "everything you ever wanted + the kitchen sink" in there to minimize context switching etc, or would you rather move it into user space for "clean structure" and "modularity" but pay a penalty for messages etc, or what about separate components that can be tested in user space, but moved into kernel space for increased efficiency? obviously, not all the pros & cons are listed above, but this is a sample of the talk(/discussion/argument/ -- argument? did _I_ say that?). other phrases included importance of "glue" between the boxes -- how do you connect the components together? large kernels: are "large" kernels inherently bad? or is it just that they weren't designed properly? could they be designed properly? can they be made to work on new architectures with parallelism & distributed environs effectively? micro kernels: do you have to pay a severe penalty for message passing? are they easier to debug? more flexible? one argument is that such kernels are more effective in providing mechanism, not policy how many primitives should be in the kernel? One point that was made near the end of the discussion was that some of the conflict seemed to arise from the style of computing that the user preferred, single machine/board based, or more distributed. Should a user want to share "his" machines resources with others? (Personally, I would say emphatically YES in the general case, but apparently some there were not of the same opinion. For those of us with no money to buy many machines of our own, the thought of stealing idle cycles from hundreds of other machines is immensely appealing. ) Terri Watson The Ohio State University elf@cis.ohio-state.edu