HDTenEightyP/NetNews huggingface dataset:
From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.os.research
Subject: Plan 9 process/thread comment?
Date: 7 Apr 92 16:30:35 GMT
Article-I.D.: darkstar.32278
Organization: Hewlett-Packard Labs
Originator: osr@ftp

In article <32234@darkstar.ucsc.edu>, rob@alice.att.com (research!rob) writes:
|> The implementers of Plan 9 are baffled by Andy Tanenbaum's recent posting.
|> We suspect we are not representative of the mainline view, but we disagree
|> at some level with most of the "GENERALLY ACCEPTED" truths Andy claims.
|> Point by point:
|> 
|> [...]

|>    - Threads should be managed by the kernel, not in user space
|> 	Better: have a decent process model and avoid this process/thread
|> 	dichotomy.
|> 

I think I'm missing something about plan 9 from the limited reading
I've done.   In particular, how do you deal with

1) The desire to support multiple threads of control cooperating
   within a single address space to exploit concurrency on a shared
   memory multiprocessor

2) The relatively higher cost of crossing the supervisor/user boundary
   (via a system call) compared to the cost of a procedure call
   (which a good compiler might inline.)

3) The need for the code which implements pre emptive scheduling to
   be executed in the hardware supervisor state of the machine

without implementing a model which has a "kernel" (supervisor)
scheduler, at least for preemption, and a "user" level library
scheduler to make scheduling of new threads as a result of such things
as mutex blocking operations as efficient as possible?

I know how to do it by introducing a single address space which is
shared by all threads of control in the entire system, but I don't
know how to do it if I allow multiple virtual address spaces on the
machine. 

-- 
Martin Fouts                  |  M/S 1U-14
EMAIL:  fouts@hpl.hp.com      |  HP Laboratories
PHONE:  (415) 857-2971        |  1501 Page Mill Road
  FAX:  (415) 857-8526        |  Palo Alto, CA 94304-1126

Nothing Left to Say (c)
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 14 Apr 92 23:53:11 GMT
Article-I.D.: darkstar.32996
Organization: University of Massachusetts, Amherst
Originator: osr@ftp


In article <32864@darkstar.ucsc.edu> andrew@rentec.com (Andrew Mullhaupt) writes:
>
>In article <32708@darkstar.ucsc.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>>2. Unix filesystem semantics -- resources organized in a tree structure
>>named by ASCII names, and operated on by open/close/read/write -- work
>>just as well in a distributed system as in a non-distributed one, unlike
>>most of their competitors.
>
>No. Memory mapped files (i.e. no read/write interface) are better. It's
>just as good an abstraction, it's simpler to use, and usually performs
>much better. Memory mapping is also fine on the network. In fact it's
>better because it means some swapping doesn't get done. It's better
>for providing heavy communication between applications than things like
>shared memory or IPC. It also simplifies the OS implementer's job and
>results in higher quality of implementation in my experience.

The concept of memory mapped files is not novel. They have not proven popular
because experience has been contrary to your claims. There's a discussion
of this issue in Butler Lampson's "Hints" paper, I believe. What 
"higher quality implementations" do you have in mind?

-- 


yodaiken@chelm.cs.umass.edu
From: rob@alice.att.com (research!rob)
Newsgroups: comp.os.research
Subject: Andy Tanenbaum hasn't learned anything
Date: 6 Apr 92 20:06:28 GMT
Organization: AT&T, Bell Labs
Originator: osr@ftp

The implementers of Plan 9 are baffled by Andy Tanenbaum's recent posting.
We suspect we are not representative of the mainline view, but we disagree
at some level with most of the "GENERALLY ACCEPTED" truths Andy claims.
Point by point:

   - The client-server paradigm is a good one
	Too vague to be a statement.  "Good" is undefined.
   - Microkernels are the way to go
	False unless your only goal is to get papers published.
	Plan 9's kernel is a fraction of the size of any microkernel
	we know and offers more functionality and comparable
	or often better performance.
   - UNIX can be successfully run as an application program
	`Run' perhaps, `successfully' no.  Name a product that succeeds
	by running UNIX as an application.
   - RPC is a good idea to base your system on
	Depends on what you mean by RPC.  If you predefine the complete
	set of RPC's, then yes.  If you make RPC a paradigm and expect
	every application to build its own (c.f. stub compilers), you
	lose all the discipline you need to make the system comprehensive.
   - Atomic group communication (broadcast) is highly useful
	Perhaps.  We've never used it or felt the need for it.
   - Caching at the file server is definitely worth doing
	True, but caching anywhere is worthwhile.  This statement is
	like saying 'good algorithms are worth using.'
   - File server replication is an idea whose time has come
	Perhaps.  Simple hardware solutions like disk mirroring solve a
	lot of the reliability problems much more easily.  Also, at least
	in a stable world, keeping your file server up is a better way to
	solve the problem.	
   - Message passing is too primitive for application programmers to use
	False.
   - Synchronous (blocking) communication is easier to use than asynchronous
	They solve different problems.  It's pointless to make the distinction
	based on ease of use.  Make the distinction based on which you need.
   - New languages are needed for writing distributed/parallel applications
	`Needed', no.  `Helpful', perhaps.  The jury's still out.
   - Distributed shared memory in one form or another is a convenient model
	Convenient for whom?  This one baffles us: distributed shared memory
	is a lousy model for building systems, yet everyone seems to be
	doing it.  (Try to find a PhD this year on a different topic.)

How about the "CONTROVERSIAL" points?  We should weigh in there, too:

   - Client caching is a good idea in a system where there are many more
     nodes than users, and users do not have a "home" machine (e.g., hypercubes)
	What?
   - Atomic transactions are worth the overhead
	Worth the overhead to whom?
   - Causal ordering for group communication is good enough
	We don't use group communication, so we don't know.
   - Threads should be managed by the kernel, not in user space
	Better: have a decent process model and avoid this process/thread
	dichotomy.


Rob Pike
Dave Presotto
Ken Thompson
Phil Winterbottom
From: ali@pyra.co.uk
Newsgroups: comp.os.research
Subject: OS design for MIMD machines
Date: 15 Apr 92 11:51:13 GMT
Article-I.D.: darkstar.33000
Originator: osr@ftp




Hi folks

I am new to this news group, so please forgive me if you have already
discussed this.

I am doing some research work into MIMD architectures (the distributed memory
kind). I have lots and lots of papers and books on topologies and designs
but nothing, absolutely NOTHING on OS design for them.

Can you please point me to any research papers/books on this issue? I really
want to know how KSR, CM-5, Meiko and nCube run their OS, handle interrupts,
handle system calls and interprocess communications across the network.

Thanks in advance for your help.


      -m--------  Ali Shirnia            Phone : +44 252 373035
    ---mmm------  Pyramid Technology     Fax   : +44 252 373135
-------mmmmmmm--  pyramid!pyrltd!ali     <England>!ukc!pyrltd!ali
-------mmmmmmmm-  ali@pyra.co.uk
From: werner@inesc.inesc.pt (Werner Vogels)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 07:01:14 GMT
Article-I.D.: darkstar.32222
Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal
Originator: osr@ftp

In article <32014@darkstar.ucsc.edu>, ast@cs.vu.nl (Andy Tanenbaum) writes:

|>    - Causal ordering for group communication is good enough

If this line means that there can be a need to order messages regarding
causality, I think that certainly in the light of a-synchronous
communication this is true.  There is a need to present events as they
have happened in real life.

If it means that causal ordering can replace all other types of
orderings (read atomic) I do not think this can stand. Causal ordering
can be sufficient in those types of groups where the applications
provides the serialization needed, for the types of applications that
lack this type of support and that need stronger garantuees on how all
participants receive messages, other orderings than causal are needed.

-- 
Werner Vogels

INESC - Distributed Systems and Industrial Automation Group
        Tel: +351 1 3100316, Fax: +351 1 525843
	e-mail: werner@inesc.pt / C=pt;A= ;P=inesc;S=werner
From: kim@kowari.uwa.oz.au (Kim Shearer)
Newsgroups: comp.os.research
Subject: Re: assumptions of OS builders
Date: 9 Apr 92 08:10:24 GMT
Organization: Sun Microsystems
Originator: osr@ftp


  Just telling someone their world picture is "false" is rather useless.
  Could we have some explanation please, then we may learn something (other
  than that you believe you are unquestionably correct).
From: mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 04:46:45 GMT
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Originator: osr@ftp

stephen@estragon.uchicago.edu (Stephen P Spackman) writes:

>In sum, operating systems have ALWAYS been OO up to a point, and the
>ideas for progressing beyond that point are ones that are coming INTO
>and not OUT OF the OO community.

	Before OO was hip, we called this "modular programming" and it
was a sign of competence, not trendiness.

	Operating systems tend to be modular if they are designed by
anyone with any kind of a clue. Yes, an operating system can be said
to be "object oriented", but let's not be any more faddish than we have
to be.

mjr.
-- 
"Sometimes if you have a cappuccino and then try again it will work OK."
						- Dr. Brian Reid, 1992
"Sometimes one cappucino isn't enough."
						- Me
From: nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 09:44:12 GMT
Article-I.D.: darkstar.32427
Organization: Continuing Education Unit, The University of Queensland
Originator: osr@ftp

jyl@burgess.Eng.Sun.COM (Jacob Levy) writes:

>[About languages for distributed programming, actually]

>While I believe this is not (yet) generally "common wisdom", I

[...]

>The issues of designing programming languages for large scale
>distributed systems are well addressed in a 1989 landmark paper
>by Ken Kahn (kahn@parc.xerox.com) and Miller (markm@xanadu.com).
>Contact Ken for an electronic copy of this paper. Extremely
>efficient runtime systems for dynamic data flow languages are
>being designed by Gudeman and Debray at UofArizona
>(gudeman,debray@cs.arizona.edu) and researchers at Xerox PARC.

Would you be able to supply me a copy of your 1989 paper, please ?


Nirad
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA
From: richard@locus.com (Richard M. Mathews)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 02:28:52 GMT
Article-I.D.: darkstar.32383
Organization: Locus Computing Corporation, Los Angeles, California
Originator: osr@ftp

crispin@csd.uwo.ca (Crispin Cowan) writes:
>It seems clear to me from this discussion that in order to have a
>successful distributed system, it is essential to plug your own system
>in response to questions like this one.  :-) :-)

That's a cute comment (and, yes, I see the smiley), but it really isn't
fair.  Of course everyone is going to be most familiar with their own
system.  Everyone is going to respond by saying what they learned or
what their group learned from developing and using that system.  So go
on, everyone; keep telling us what your system is, how it works, why it
works well, and why it works poorly.

Richard M. Mathews			Lietuva laisva = Free Lithuania
Internet:   richard@locus.com		Brivu Latviju  = Free Latvia
UUCP:	    ...!uunet!lcc!richard	Eesti vabaks   = Free Estonia
MIL/BITNET: richard%lcc@UUNET.UU.NET	        WE  DID  IT!!!
From: mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 20:17:57 GMT
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Originator: osr@ftp

daves@comp.lancs.ac.uk (Dave Stow) writes:
>>   - Microkernels are the way to go

>Yeah - Microkernels seem to be a good way of providing modularity and easy
>porting, as little of them _has_ to be machine dependent. The services that
>microkernels should actually provide seem to be rapidly decreasing as
>time goes on...

	The thing to remember about microkernels is that it's just a
shuffling around of services. The services still have to be provided
someplace, and often they're just as "heavy" if they're in user-mode
or in the kernel. It's not as if going to a microkernel really buys you
anything as far as that you can somehow magically make the system get
the same amount of work done with less effort. On the contrary.

	Microkernels are a good way of providing modularity, but then
so is just disciplined programming and keeping it simple. It's not
dramatically harder to write an operating system than any other
application, and the reason they're turning into plate 'o'spaghetti
is simply because they're not designed in a modular manner with
decent (not newer and better) abstractions. So, sure, a microkernel
will provide good modularity - so will developing *ALL* your applications
as coroutines that communicate through shared memory - but we don't
do that all the time because sometimes it's actually more complex
and error prone than just developing your application (or kernel) to
be modular internally and leaving it at that.

	So the microkernel fanatics squeeze everything out of the
microkernel and into user space. It's *STILL* there, and it's
just as bloated - you've moved it. Big deal. Microsoft Windows NT
is a microkernel, but there's this bloated user executive sitting
right above it that has a windowing system built in, network stacks
and lord knows what else. In the long run, what's the difference?

mjr.
-- 
	This is an OPEN .signature. You can license it directly from the
author. The fact that it is seen across the world on USENET makes it a
De Facto STANDARD, too. Anyone who doesn't use this .signature is clearly
trying to lock you in to a proprietary .sig! 	- notebooks of a heretic


----- End Included Message -----
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 17 Apr 92 13:26:11 GMT
Article-I.D.: darkstar.33185
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <1992Apr17.052709.9693@pasteur.Berkeley.EDU> johnm@cory.berkeley.edu (John D. Mitchell) writes:
>[...]
>I would buy that each of us has a different definition of what 'distributed
>computing' means (I will even go so far as to claim that each of us has
>*multiple* definitions of what it means based on different contexts).  Each
>of us has our own biases, expertise, etc.  I think he realizes that Sprite
>has tried some neat things (for the domain that it set out for) and
>achieved them.  I feel that there are some lessons to be learned from the
>Sprite experience.  I also think that this is exactly what research is all
>about.  Sure it's important to make distributable (:-) products for general
>use too.  It's just that the gap between the currently envisioned
>super-WAN's (for lack of a better term) and the departmental sized
>distributed computing that Sprite focuses on is simply huge.

Great, I'm glad we more or less are in agreement with each other.
Probably, John has a different point of view.  I certainly think that
Sprite has contributed a great deal.  John has been one of the most
creative and prolific researchers in the field for many years, and
his systems are always interesting.

The irony in all this, for me at least, is that one of the clevest
ideas to come out of Sprite so far is the log-structured file system.
But, it turns out that this is a new abstraction: we just heard a
database researcher talk about how LFS changes the way you should build
your database; basically, if you are running over a file system you need
to know if the "abstract" model is LFS or NFS to optimize performance.

So (gasp), even John may have accidently proposed a new abstraction
here....


-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: piet@cs.ruu.nl (Piet van Oostrum)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 16 Apr 92 09:45:17 GMT
Organization: Dept of Computer Science, Utrecht University, The Netherlands

>>>>> andrew@rentec.com (Andrew Mullhaupt) (AM) writes:

AM> No. Memory mapped files (i.e. no read/write interface) are better. It's
AM> just as good an abstraction, it's simpler to use, and usually performs
AM> much better. Memory mapping is also fine on the network. In fact it's
AM> better because it means some swapping doesn't get done. It's better
AM> for providing heavy communication between applications than things like
AM> shared memory or IPC. It also simplifies the OS implementer's job and
    ^^^^^^^^^^^^^
AM> results in higher quality of implementation in my experience.

If you have a distributed file system, and memory mapped files with the
proper semantics (i.e. changes to the file are immediately visible to all
processes that have the file mapped), you essentially have shared virtual
memory.
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')
From: maniattb@fornax.cs.rpi.edu (Bill Maniatty)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 23:53:15 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY
Originator: osr@ftp

I think that Ken Birman's observations about:
        1. functionality driving design
	2. trends in computing (interesting applications)
are important issues.  I'm not ready to take the Tanenbaum challenge quite
yet, but I am interested in these issues. 

The temptation is to examine the nuts and bolts level of OS design,
but we also need to consider just what kind of problems we are trying to
solve.  I understand that applications are not really in the scope of
this group, however a big picture approach might offer some insight.

Thanks,

Bill Maniatty
-- 
|
|	maniattb@cs.rpi.edu - in real life Bill Maniatty
|
From: johnm@cory.berkeley.edu (John D. Mitchell)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 14 Apr 92 01:14:07 GMT
Organization: University of California, at Berkeley
Originator: osr@ftp

In article <32804@darkstar.ucsc.edu> emery@Dr_No.mitre.org (David Emery) writes:
[...]
>Incidentally, does everyone agree with the following:
>	0.  Operating Systems are best implemented in high-level
>	    languages.  
>If so, does this argue for the use of higher-level languages in
>contemporary O.S. implementations?  Is C (which has mediocre support
>for data abstraction and/or object orientation) too low level?  

No.  GeoWorks' PC/GEOS system is written in a (currently) in-house object
oriented superset of uSoft's MASM i80x86 assembly language.  Yes, this
system is definitely non-portable to other architectures (but so what? Can
your system run both on the desktop and out of ROM on a Poquet?... That's
what I thought. :-).

The object oriented support is accomplished through kernel level support
for objects (creation, etc.) and message handling.

Just my $0.02,
	John D. Mitchell
	johnm@cory.Berkeley.EDU

P.S.	I speak solely for myself.
From: glass@postgres.Berkeley.EDU (Adam Glass)
Newsgroups: comp.os.research
Subject: pointer to origin of filesystem switch
Date: 14 Apr 92 22:25:35 GMT
Article-I.D.: darkstar.32995
Organization: Organization is evil.
Originator: osr@ftp
From: glass@postgres.Berkeley.EDU (Adam Glass)
Newsgroups: comp.os.research,comp.protocols.nfs
Subject: pointer to origin of filesystem switch
Date: 14 Apr 92 15:25:28
Organization: Organization is evil.
Distribution: world
NNTP-Posting-Host: erewhon.berkeley.edu


I need a pointer to the original paper(s) describing filesystem
switches such as sun's vfs/vnodes.

later,
Adam Glass
UCB
--
Adam Glass                           |Internet: glass@postgres.Berkeley.Edu
various roles at Berkeley	     |Home    : glass@solipsist.Chaos.org
		     "reality is for dead birds"
Newsgroups: comp.os.research
From: rcbc@cs.cornell.edu (Robert Cooper)
Subject: Re: Have we learned anything in the last 20 years?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Thu, 16 Apr 1992 18:40:09 GMT

What's a nano-kernel? What's a micro-kernel? Doesn't anyone remember that
the word "kernel" was used to emote something small and central. Clearly we
are seeing a continual devalueing of these terms.

In article <32498@darkstar.ucsc.edu> dm@think.com (dave mankins) writes:

>   >	So the microkernel fanatics squeeze everything out of the
>   >microkernel and into user space. It's *STILL* there, and it's
>   >just as bloated - you've moved it. Big deal. [....] In the long run, what's
>   >the difference? 
>
>   The major difference I see lies in the vast superiority of the user-level
>   debugging environment.  KADB, bleah.  I want KSABER, or at least KDBX.

Most user's don't write and debug kernels (I hope). Most don't even know
what a kernel is. Why should the user pay for something (crossing
supervisor-user boundaries because the file system is in user-space) when
they will never debug the kernel? 

>   A second difference lies in the relative fail-soft behavior of user
>   programs versus kernel programs (my user-level server dies, I restart
>   it, maybe under dbx or Saber; 

Again, if I'm running an airline reservation system, I don't care if
the "kernel" keeps running when my database crashes. In fact as a
programmer I don't really care if my workstation keeps running when my
file server crashes since I can't get any work done. 

>   my kernel-level server dies, I go get a
>   cup of coffee, and check the new acquisitions in the library while
>   waiting for the reboot and its disk-check to complete). 

Any decent file system wouldn't take 0rder(filesystemsize) to reboot
after an unclean crash. Unix has been behind the technology in this
area for a long time. 

>   A further difference is: maybe it's not ``there'', maybe it's down the
>   hall.  After all, once you've put the narrow pipe between your
>   millikernel (probably really a decikernel) and your server, it is only
>   performance that keeps the server and the kernel on the same CPU.

This is a valid point, so long as the interface will work well (reliably,
efficiently) over the network.

I think that the idea of a microkernel is useful to the extent that it
provides a fixed, published, widely agreed interface to low-level OS
services that are needed in practically all application areas. It provides
a high degree of modularity between the kernel and higher OS services that
helps to prevent spaghetti module interconnections.  But when you actually
configure an operating system for a particular market, there should be no
requirement for the micro-kernel boundary to be the supervisor-user mode
boundary, since this costs something, and is not of much benefit to the
end-user. 

                 -- Robert Cooper

--