9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-10 11:35 Matt
  0 siblings, 0 replies; 38+ messages in thread
From: Matt @ 2001-04-10 11:35 UTC (permalink / raw)
  To: 9fans


>The best-configured Windows system is still inadequate
>(without a lot of third-party software)

it'a got Solitaire what more do you need?

Matt



^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-17  8:35 nemo
  0 siblings, 0 replies; 38+ messages in thread
From: nemo @ 2001-04-17  8:35 UTC (permalink / raw)
  To: 9fans


The funny thing is that services like drivers, file systems, et al.
are out of the kernel in Plan 9 since they come mostly from the network.
Certainly, you get your drivers in the kernel, but I'm used to import
many of them from the network. So, you can replace, develop and debug much
`kernel software' in user space, which IMHO was the original aim of the
uKernel camp. What I like most is that the system design is not pushed too far
just to get more stuff out of the kernel.

I'd say that Plan 9 has a well-engineered kernel: Not micro, not macro. ☺


:  Andrey A Mirtchovski <aam396@mail.usask.ca> wrote:
:  >i seem to remember reading somewhere a reasoning on why it was chosen to
:  >implement p9 with a monolithic kernel, instead of a micro one..
:
:  Charles Forsyth <forsyth@vitanuova.com> replied:
:  >the implied comparison is false.  to start with, the plan 9 kernel
:  >is not  `monolithic'.  it is highly modular.
:
:  I've heard people use the term `monolithic' to describe an operating
:  system that may or may not have been modular, but was a `monolithic
:  monitor'. Years ago, I was a junior on a project developing such a



^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-10 11:56 forsyth
  0 siblings, 0 replies; 38+ messages in thread
From: forsyth @ 2001-04-10 11:56 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

it's possible to do this with plan 9.  in fact, it's usually quicker, because
once the configuration is set up on the file server (even if that's on a kfs
partition of a cpu server), all the terminals share the same configuration,
and you just have to boot them.


[-- Attachment #2: Type: message/rfc822, Size: 3530 bytes --]

To: cse.psu.edu!9fans
Cc: einstein.ssz.com!hangar18
Subject: Re: [9fans] micro vs monolithic kernels
Date: Mon, 9 Apr 2001 16:52:23 -0500 (CDT)
Message-ID: <Pine.LNX.3.96.1010409164128.14587X-100000@einstein.ssz.com>


On Mon, 9 Apr 2001, Russ Cox wrote:

> you wouldn't expect to set up a full-blown windows nt
> file server in a few hours and have it work.  you wouldn't
> (or at least shouldn't) expect to sit down with the red hat
> box and have a linux system completely ready to go in a
> few hours.

I'll have to disagree. My day job is taking GA code for a very large
software/hardware company and testing it on new OS'es as they come out
the door. I manage a group of 5 engineers who spend their week doing about
25-50 OS loads a week and then running the resultant through an automated
testsuite.

On average a MS or Linux box takes between 2-3 hours to config once the
binaries are installed and the system rebooted. I can have a linux box up
and running (sendmail, bind, majordomo, etc.) up and running in under two
hours myself (and have been hitting that target for several years now).
This doesn't include kernel compile time.

So, trying to set the 'base line' standard to install and config a box
outside of 8 hours (a regular work day) is being unreasonable. It should
take x number of hours to setup networking, name resolution, MTA, etc. The
process should be scripted as none of these apps should have ANY hardware
dependency at all.

Saying that your OS won't allow one to configure these base services in a
reasonable and repeatable amount of time is a cop-out.

You guys should work in a 'production' environment, you're getting flabby
around your pre-frontals...

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-10 11:50 forsyth
  0 siblings, 0 replies; 38+ messages in thread
From: forsyth @ 2001-04-10 11:50 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

i think that's misleading:  we use plan 9 for production work, generally quite happily
(much happier than we would be using most other systems), and it works well.
and that's a Good Thing.


[-- Attachment #2: Type: message/rfc822, Size: 1906 bytes --]

To: cse.psu.edu!9fans
Subject: Re: [9fans] micro vs monolithic kernels
Date: Mon, 09 Apr 2001 15:36:52 -0600
Message-ID: <200104092136.f39Laqi05988@orthanc.ab.ca>

>>>>> "Jim" == Jim Choate <ravage@ssz.com> writes:

    Jim> You guys should work in a 'production' environment, you're
    Jim> getting flabby around your pre-frontals...

No, you should run 'production' software in your 'production' environment.
We aren't running a 'production' environment here. And that's a Good Thing.

--lyndon

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-10 10:52 forsyth
  0 siblings, 0 replies; 38+ messages in thread
From: forsyth @ 2001-04-10 10:52 UTC (permalink / raw)
  To: 9fans

>>n particular have been getting worse with each release.  Even Windows
>>installations aren't much better -- you are completely out of luck if
>>anything goes wrong.

not completely out of luck.  after a few hours of a promised 30 minute installation for
windows/me, it refused to proceed until i told it where to find bits of itself on its own cd
but with that information (``you're asking me??'') it shuffled off and completed
a few hours later.

it wasn't worth it.



^ permalink raw reply	[flat|nested] 38+ messages in thread
[parent not found: <200104092210.RAA06371@einstein.ssz.com>]
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09 22:00 jmk
  2001-04-09 22:30 ` Jim Choate
  0 siblings, 1 reply; 38+ messages in thread
From: jmk @ 2001-04-09 22:00 UTC (permalink / raw)
  To: 9fans

On Mon Apr  9 17:55:42 EDT 2001, ravage@ssz.com wrote:
>
> I have to disagree here as well. You wouldn't if you were out there all
> along with your willies swinging in the wind.
>
> I don't and wouldn't do that to my people.
>
> I can take a newbie and have them walk through my teams script (it's
> mostly automated) and they can do it almost as fast. It takes us about 2
> weeks to get somebody up to speed and regularly, reliably hitting our
> standard performance markers.
>
> Plan 9 has a ways to go, that is without a doubt...;)

Ah, a room full of monkeys (or would that be armadillos in texas).


^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09 21:47 presotto
  0 siblings, 0 replies; 38+ messages in thread
From: presotto @ 2001-04-09 21:47 UTC (permalink / raw)
  To: ravage, 9fans

Sounds like we have a volunteer with the manpower
and correct expertise to make our system install
process better.

Thank you for volunteering Jim!  Your whole
group will indeed get free t-shirts when its
done.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09 21:43 Russ Cox
  2001-04-09 22:16 ` Jim Choate
  0 siblings, 1 reply; 38+ messages in thread
From: Russ Cox @ 2001-04-09 21:43 UTC (permalink / raw)
  To: 9fans

sorry, i didn't qualify that properly.
you wouldn't expect, having just been exposed to
windows for the first time, to set up an nt file
server properly in a few hours.  ditto for linux.

once you've done it a few times, and once you know
your way around the system, sure, all of them become
much quicker to install.  for the last six years, i've
run a linux internet gateway at my old high school.
the first time i set it up it took me hundreds (!) of
hours, despite familiarity with linux.  (the computing
environment there was quite peculiar and inserting linux
required much tailoring.)  the last time i set it up
it took three hours.

i agree that it'd be great to have the plan 9 cpu and
file servers be easier to install.  doing a cpu
install program wouldn't be too hard.  doing a file
server install program will require waiting for the
new file server, since the current one doesn't allow
arbitrary processes to run on it: what you see is
all you get.

russ


^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09 21:15 Russ Cox
  2001-04-09 21:52 ` Jim Choate
  2001-04-09 22:10 ` Mike Haertel
  0 siblings, 2 replies; 38+ messages in thread
From: Russ Cox @ 2001-04-09 21:15 UTC (permalink / raw)
  To: 9fans

 	one question does anyone find bell labs' documentation a poor disgrace to
	software engineering's design process.

if we knew what it was going to look like when
we finished, what would be the point of building it?

more seriously, we're all happy to help you get going,
but setting up a plan 9 file or cpu server is not like
setting up a toaster.  it's not just going to work.
you need to get used to the way the system works so you
can figure out what went wrong when things do go wrong.

you wouldn't expect to set up a full-blown windows nt
file server in a few hours and have it work.  you wouldn't
(or at least shouldn't) expect to sit down with the red hat
box and have a linux system completely ready to go in a
few hours.  because plan 9 is a research system while those
are commercial systems, you should expect even less in terms
of `works right out of the box'.

that's not to say that it actually is harder to install than
windows or linux.  i think installing a terminal is actually
much easier in plan 9 than in the various linux distributions
i've used.  there's no similar program to lead you through
installing a cpu server, and certainly not one to lead you
through installing a file server.

if you go at it with the right frame of mind, plan 9
is a lot of fun and quite pleasant to use.
it _will_ be frustrating at times (especially when
setting up a file server), but in general those
times are few and far between, and it's more
rewarding than frustrating.

russ


^ permalink raw reply	[flat|nested] 38+ messages in thread
[parent not found: <john@cs.york.ac.uk>]
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09 10:19 forsyth
  0 siblings, 0 replies; 38+ messages in thread
From: forsyth @ 2001-04-09 10:19 UTC (permalink / raw)
  To: 9fans

the nvram isn't important.  it will prompt for the values if necessary
and that's the easiest way to check that it is correctly booting the cpu server
kernel not the terminal kernel.  once that's going you can worry about setting
up the nvram.

i set a cpu/auth system up recently (without a separate file server).
i think this is what i did:

0. build /lib/ndb/local correctly; in many ways, the hard part.  you need to get
    the ipmask= and ipsubmask= and ip-net= set up to describe your network correctly.
    include proto=il in the entry for each plan 9 machine.
    include default auth= and fs= entries in the network or subnet entries.
1. cd /sys/src/9/pc; mk 'CONF=pccpudisk' install
2. 9fat: ; cp /386/9pccpudisk /n/9fat/9pccpudisk
3. change /n/9fat/plan9.ini, bootfile=sdC0!9fat!9pccpudisk  (replacing sdC0 by your disc name)
4. make sure /lib/ndb/auth contains

hostid=bootes
	uid=!sys uid=!adm uid=*

  this lets the cpu server believe that the auth server can vouch for others as described

5. cd /rc/bin/service; mv il566 _il566; mv tcp567 _tcp567
6. cd /rc/bin/service.auth; ensure the following contents
	tcp567:
		#!/bin/rc
		/bin/auth/auth.srv -d $3
	il566:
		#!/bin/rc
		/bin/auth/auth.srv -d $3
	chmod a+rx tcp567 il566
7. modify /rc/bin/cpurc to uncomment the lines that are commented-out:

	# uncomment the following for booting other systems
	ip/dhcpd
	ip/tftpd

	# services available to networks (remove -t /rc/bin/service.auth
	# if this isn't an auth server)
	auth/keyfs -m /mnt/keys /adm/keys
	aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth il
	aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth tcp
	auth/cron

   you can add a switch($sysname){ ... } to select different cpu server services
   if you've got more than one and only one is acting as auth server and file server.

8. if you're not setting up a separate file server (using the /sys/src/fs kernel) but are
   serving files from a kfs partition on the cpu/auth server, then further do
	8a.  cd /rc/bin/service; mv il17008 _il17008
	8b.  in /rc/bin/cpurc above, after starting auth/keyfs and before aux/listen do
		disk/kfscmd listen



^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-09  9:09 forsyth
  2001-04-09  9:32 ` Dave Iafrate - CSCI/F1997
  0 siblings, 1 reply; 38+ messages in thread
From: forsyth @ 2001-04-09  9:09 UTC (permalink / raw)
  To: 9fans

>>i seem to remember reading somewhere a reasoning on why it was chosen to
>>implement p9 with a monolithic kernel, instead of a micro one..

the implied comparison is false.  to start with, the plan 9 kernel
is not  `monolithic'.  it is highly modular.
in particular, the interfaces between the kernel and device drivers,
and between the IP device driver and its protocol and media drivers,
are all narrow, well-structured interfaces.  indeed, some things that
are implemented by `system calls' in other systems are just separable,
configurable device drivers in this one.

modularity is not in an `iff' relationship with structuring using message passing and processes.

another answer is possibly that they wanted it to do something useful.
perhaps there is a connection with cray's comment:

	If you were plowing a field what would you rather use, 2 strong oxen or 1024 chickens? -Seymour Cray



^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [9fans] micro vs monolithic kernels
@ 2001-04-08 19:36 presotto
  0 siblings, 0 replies; 38+ messages in thread
From: presotto @ 2001-04-08 19:36 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

Because you need a brain the size of a planet to design a
microkernel based system and we only have egos that big.

[-- Attachment #2: Type: message/rfc822, Size: 2214 bytes --]

From: Andrey A Mirtchovski <aam396@mail.usask.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] micro vs monolithic kernels
Date: Sun, 8 Apr 2001 11:55:22 -0600 (CST)
Message-ID: <Pine.GSO.4.10.10104081148380.17278-100000@ultra5d.usask.ca>

hello all,

i seem to remember reading somewhere a reasoning on why it was chosen to
implement p9 with a monolithic kernel, instead of a micro one..

i can't find the link anymore, so i'd like to ask for, either pointers to any
documents discussing this, or a brief explanation in an email from anyone,
who feels they can give me one..

let me state the question clearly: why did the bell-labs team chose to
implement plan9 using a monolithic kernel?


i realize that a comparative analysis of the two architectures can lead to a
flamefest, so i ask only for facts :)


andrey

^ permalink raw reply	[flat|nested] 38+ messages in thread
* [9fans] micro vs monolithic kernels
@ 2001-04-08 17:55 Andrey A Mirtchovski
  0 siblings, 0 replies; 38+ messages in thread
From: Andrey A Mirtchovski @ 2001-04-08 17:55 UTC (permalink / raw)
  To: 9fans

hello all,

i seem to remember reading somewhere a reasoning on why it was chosen to
implement p9 with a monolithic kernel, instead of a micro one..

i can't find the link anymore, so i'd like to ask for, either pointers to any
documents discussing this, or a brief explanation in an email from anyone,
who feels they can give me one..

let me state the question clearly: why did the bell-labs team chose to
implement plan9 using a monolithic kernel?


i realize that a comparative analysis of the two architectures can lead to a
flamefest, so i ask only for facts :)


andrey



^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2001-04-17  8:35 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-10 11:35 [9fans] micro vs monolithic kernels Matt
  -- strict thread matches above, loose matches on Subject: below --
2001-04-17  8:35 nemo
2001-04-10 11:56 forsyth
2001-04-10 11:50 forsyth
2001-04-10 10:52 forsyth
     [not found] <200104092210.RAA06371@einstein.ssz.com>
2001-04-09 22:12 ` Jim Choate
2001-04-10  9:00   ` Boyd Roberts
2001-04-09 22:00 jmk
2001-04-09 22:30 ` Jim Choate
2001-04-09 21:47 presotto
2001-04-09 21:43 Russ Cox
2001-04-09 22:16 ` Jim Choate
2001-04-10  8:59   ` Douglas A. Gwyn
2001-04-10  9:00   ` Boyd Roberts
2001-04-09 21:15 Russ Cox
2001-04-09 21:52 ` Jim Choate
2001-04-09 21:36   ` Lyndon Nerenberg
2001-04-09 22:08     ` Jim Choate
2001-04-09 22:34       ` Lyndon Nerenberg
2001-04-10  0:45       ` Steve Kilbane
2001-04-10  0:28         ` Jim Choate
2001-04-10  8:18           ` Steve Kilbane
2001-04-10  8:57       ` Douglas A. Gwyn
2001-04-09 21:40   ` William Josephson
2001-04-09 22:10     ` Jim Choate
2001-04-09 22:16       ` William Josephson
2001-04-09 22:42   ` Dan Cross
2001-04-09 23:10     ` Jim Choate
2001-04-10  0:30       ` Dan Cross
2001-04-09 22:10 ` Mike Haertel
     [not found] <john@cs.york.ac.uk>
2001-04-09 14:33 ` John A. Murdie
2001-04-09 23:31   ` Steve Kilbane
2001-04-09 10:19 forsyth
2001-04-09  9:09 forsyth
2001-04-09  9:32 ` Dave Iafrate - CSCI/F1997
2001-04-09 16:14   ` Douglas A. Gwyn
2001-04-08 19:36 presotto
2001-04-08 17:55 Andrey A Mirtchovski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).