HDTenEightyP/NetNews huggingface dataset:
From: kiosk!snark!pmetzger@uunet.UU.NET (Perry E. Metzger)
Newsgroups: comp.os.research
Subject: What's New in O.S. research
Date: 10 Apr 92 21:56:46 GMT
Organization: Lehman Brothers
Originator: osr@ftp

In article <32548@darkstar.ucsc.edu> yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:

   3. It is possible to perform significant, on line, "compilation" of
   multi-layered o.s. code. The use of this method by Massalin, seems to me to
   be one of the most significant advances in the state of the art in
   recent years.

I would heartily agree. Henry Massalin's work is seminal.
Unfortunately, its so paradigm-shaking that many people will ignore it
for the forseeable future.

For those not in the know, Henry's operating system, Synthesis,
operates on entirely novel concepts, including the run time generation
of much of its own code, thus permitting vast optimizations.

Incidently, Henry's thesis defense was today.
--
Perry Metzger		pmetzger@shearson.com
--
"That government governs best which governs least."
		-- Thomas Jefferson, former US President and early libertarian.
Restore the American Dream: Andre Marrou for President! Vote Libertarian!
Libertarian Party info: Phone 1-800-682-1776, E-Mail 345-5647@mcimail.com
From: bsmith@ecst.csuchico.edu (Charles Bennett Smith)
Newsgroups: comp.os.research
Subject: Re: Microkernels and Nanokernels
Date: 9 Apr 92 14:02:02 GMT
Organization: California State University, Chico
Originator: osr@ftp

In article <32425@darkstar.ucsc.edu> glenn@ready.eng.ready.com (Glenn Kasten) writes:
>
>A microkernel is usually defined as a relatively small kernel which is
>primarily intended to be used in implementing higher-level operating
>systems, rather than application programs.  Ready Systems uses the term
>"Nanokernel", to mean an even smaller kernel which is primarily
>intended to be used in implementing microkernels.

Ok, so what kind of services are provided by a nanokernel?  What kind of
services are provided by a microkernel?

Scheduling, semaphores, monitors, memory management, interrupt management?
What else?

Can someone give a concise picture of the layering and what is at each
level?

-- Bennett

-- 
Lassen Research                                   Bennett Smith
300 Salem Street                                  bsmith@ecst.csuchico.edu
Chico California  95928                           (916) 343-6421
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 02:16:26 GMT
Article-I.D.: darkstar.32428
Organization: University of Chicago CILS
Originator: osr@ftp

In article <32385@darkstar.ucsc.edu> ken@cs.cornell.edu (Ken Birman) writes:
|In article <32221@darkstar.ucsc.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
|>(on the subject of asynchronous communication requiring causality)
|>Except, the user-perceived difference in the two is just that one
|>works better. So are you really providing an argument against RPC, or
|>just against naivete in its implementation?
|
|I agree entirely with this.  What we favor is a "virtual" approach in
|which the user sees the simplest possible user interface, while the
|system cleverly sends messages asynchronously in such a way that nobody
|notices.
|
|With regard to RPC, though, the problem is that the actual semantics of
|RPC are that the call is "done" when the caller regains control of the
|processor.  So, this very strong semantic really limits the degree to
|which an implementation can be clever...

Surely the semantics are that the call be *seen* to be done when the
routine returns; the synchronisation can be delayed until at least the
next request (so long as it is understood that a Void return means
that NO information, not even there-was-no-error, is passed back).
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 17 Apr 92 17:25:27 GMT
Organization: University of Michigan, IFS Project
Originator: osr@ftp

In article <1992Apr17.053347.10692@pasteur.Berkeley.EDU> rcbc@cs.cornell.edu (Robert Cooper) writes (among other things):

>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? 

Because the question isn't whether users pay, the question is HOW they pay.
With a "macro-kernel" (sorry , but I can't think of anything else) they pay
in up front price (because it was hard to build and debug) and in availability
(for the same reason).

>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. 

True, IF the reservation system is the only application on the machine (which
it often isn't, even at the airlines).  And perhaps the real issue is that 
systems in general shouldn't be implemented as a single integrated glop, so 
that the whole reservation system doesn't come down because one agents user 
interface crashes.

>                 -- Robert Cooper

Sarr Blumson
Newsgroups: comp.os.research
From: msagen@autobahn.ardfa.calpoly.edu (/morgen/sagen)
Subject: File Systems Research
Organization: Applied Research and Development, San Luis Obispo CA
Date: Thu, 16 Apr 1992 04:09:31 GMT

I'm gathering information on current developments in file systems, and I'd
appreciate people's opinions on which are the more prominent papers/people
in this area.

Thanks much...

Morgen Sagen
Cal Poly, SLO, CA
From: dfields@urbana.mcd.mot.com (David Fields)
Newsgroups: comp.os.research
Subject: Microkernels (was Re: Have we learned anything in the last 20 years?)
Date: 9 Apr 92 21:21:42 GMT
Organization: Motorola, Inc.  Computer Group
Originator: osr@ftp

In article <32422@darkstar.ucsc.edu>, mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) writes:
>	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.

They can be just a re-shuffle but they don't have to be and hopefully
won't be, eventually.

>	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.

I agree with your point that a kernel can be modular with out
being u-kernelized.  However, not all of us get to write our
own kernel so we have to make do with what we buy from a
supplier which, for reasons I won't go into, we can't change.
If the only way to force our supplier to provide true modularity
(clean interfaces and data encapsulation) is to encourage them
to use u-kernel techniques then so be it.

If the services in user-land are written in a way that's even
remotely modular, people in the real-world who have to port
the system may have a chance at understanding the undocumented
designs that we have all come to expect.  Then, there's a reasonable
chance that the service can be modified with fewer dangers
and in a more reasonable time frame than in current products.
--
Dave Fields	Motorola Computer Group		dfields@urbana.mcd.mot.com
SVR4: The Winchester Mystery Kernel		uiucuxc!udc!dfields


Xref: sparky comp.os.research:491 comp.protocols.nfs:1302
Newsgroups: comp.os.research,comp.protocols.nfs
Subject: pointer to origin of filesystem switch
From: glass@postgres.Berkeley.EDU (Adam Glass)
Date: 14 Apr 92 15:25:28
Distribution: world
Organization: Organization is evil.
Originator: osr@ftp
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"
From: grieb@girtab.usc.edu (Charles Grieb)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 11 Apr 92 07:52:34 GMT
Article-I.D.: darkstar.32685
Organization: University of Southern California, Los Angeles, CA
Originator: osr@ftp

jones@pyrite.cs.uiowa.edu (Douglas W. Jones) writes:

>  Finally, another lesson from the 1960's applies.  Make your hierarchy
>  transparent (see Parnas's old paper on transparency and opacity in
>  hierarchically designed systems).  Let me use datagrams or some other
>  low level primitive on those occasions when the high level primitives
>  you've supplied don't match my application's needs!

YES YES YES YES YES!!!!

Too many system designers think their hierarchy is just so clever that
nobody should even know how it is implemented at a lower level.  Why
they might *bypass* it and not use this wonderful code with clever
typedef and structure names that the designer worked so hard on!  What
a shame!

Really, if people work too hard on the hierarchy, they obviosly have
removed time from the making the low-level stuff as good as possible.
I'd much rather have a hierarchy that is described with code that says
"here is an example of how RPC (or whatever) can be implemented on
our system, this example is quite simple and a real implementation may
require more code..."

Bill Spitzak
From: lm@slovax.Eng.Sun.COM (Larry McVoy)
Newsgroups: comp.os.research
Subject: Re: Plan 9 process/thread comment?
Date: 10 Apr 92 05:54:25 GMT
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Originator: osr@ftp

fouts@hplmf.hpl.hp.com (Martin Fouts) writes:
: OK.  This is all good.  But it doesn't really address the question of
: interaction.  It still costs you 250 instructions to get into the
: kernel, as opposed to 1 instruction to get into a library level
: scheduler, and I doubt it is going to get any cheaper.  I guess that
: is why you have a co-routine package.  The problem comes when I want
: to use the speed of the co-routine package and multiple cpus.  With
: your approach I give up one or the other.

At the risk of appearing stupid (yeah, some risk :-), or getting fired
for arguing w/ corporate culture, I'll stick in my two cents again
about threads.

I don't think threads buy you much.  The main problem with user level
thread packages is that they block the whole process when a thread does
I/O.  OK, says Joe Thread developer, I'll just provide threads that
have kernel context.   But when you add kernel support for that thread,
haven't you turned that thread back into a process?  What's the
difference?  Anything that the kernel manages is within epsilon of a
process and anything else is of limited usefulness.

I personally like the Plan-9 model of processes, as described here
recently, much better than any of the various thread models.

Since my opinion differs so dramatically with the some Sun opinions,
you will do me a great favor by remebering that it is, after all, my
opinion.
---
Larry McVoy			(415) 336-7627			 lm@sun.com
From: glew@pdx007.intel.com (Andy Glew)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 12 Apr 92 03:59:13 GMT
Article-I.D.: darkstar.32793
Organization: Intel Corp., Hillsboro, Oregon
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Instead, for the second act, I hereby challenge all the people who have commented
>on my list to do better.

How about:

    A single namespace (for files, processes, sockets, IPC objects, etc., etc.)
    is really convenient.

Now, maybe this wasn't learned in the last few years, but there seem
to be people constantly trying to get around this rule (System V IPC).

And, similarly, people constantly seem to be fixing up the namespace
problems (Plan 9).

% A couple of minutes later --DL

>   2. Synchronous (blocking) communication is easier to use than asynchronous.
>         Starting a send, then going off to do something, followed by getting
>      an interrupt when the send is done is a nightmare to program.  If you
>      must do something while waiting for the reply, put that code in another
>      (synchronous) thread.  The biggest problem in the computer industry is
>      not slow machines, but hairy, unreliable software.  Using asynchronous
>      communication just makes the problem worse.

Bogus!

If you want synchronous communication, do

    	sendid := asynch_send_start();
    	wait_for_completion(sendif);

I.e. synchronous communication is trivially synthesized from asynchronous.

Asynchronous communication can be synthesized from synchronous, but
you have to get another thread/process to do the actual op for you.

Anyone who has dealt with so-called asynchronous I/O in the SVr4
kernel, or repaired fast diskcopy routines (I believe that even BSD
backup/restore now uses pseudo-asynchronous I/O using a lot of
processes connected by pipes) will agree that simulating asynch on top
of synch is a bitch.

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: davecb@nexus.yorku.ca (David Collier-Brown)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 13 Apr 92 12:37:21 GMT
Article-I.D.: darkstar.32799
Organization: York University
Originator: osr@ftp

ken@cs.cornell.edu (Ken Birman) writes: [in a discussion of RPC, streams, etc] 
|Rephrased, then, my feeling is that RPC, in the form that the vendors
|are providing it to the UNIX community, is hopelessly synchronous -- and that
|the politics of the situation make it much more likely that this can be
|attacked by introducing new abstractions (gasp!) like process groups and
|group communication then by trying to talk the DCE people into changing
|DCE to use something along the lines of the work done in Hermes or Mercury.

   As a minimalist by trade, I'd rather see a construct like lisp's ``future''
provided as a layer that optionally sits on a ``standard'' RPC.  Specifically,
I'd like to say

	p = future(some(function,possibly,using,rpc));
	...
	...
	if ((x=(*p)())->q != NULL) {
		...

I claim that this is a usable form of asynchronicity, usable by the
same class of ``ordinary'' programmer who would prefer the simple
semantics of RPC and synchronous i/o.

- - --dave

[ps: for those who don't know the notation, future arranges for a
function to be executed somehow, possibly in parallel, and returns a
function that, when evaluated, returns the result of the first
function.  Or waits for it to finish if it's not done yet.  Obviously
the C variant is restricted to pure function-return parameter
passing...  This is better done in other languages]

-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | He's so smart he's dumb.
CANADA. 416-223-8968  |     -- Joyce Collier-Brown
From: calton@cs.columbia.edu (Calton Pu)
Newsgroups: comp.os.research
Subject: Synthesis bib
Date: 13 Apr 92 20:30:52 GMT
Originator: osr@ftp

Please see the attached bib list.  Henry Massalin just defended on
4/10/92 and his revised dissertation will be made available as a
Columbia TR some time in May.

		-Calton-

@InProceedings(Pu91b,
		Author="Pu, C. and Massalin, H.",
		Key="Pu and Massalin",
		Title="Quaject Composition in the Synthesis Kernel",
		BookTitle="Proceedings of International Workshop on
			Object Orientation in Operating Systems",  
		Organization="IEEE/Computer Society",
		Address="Palo Alto",
		Year="1991", Month="October"
	   )

@TechReport(LockFree,
		Author="Massalin, H. and Pu, C.",
		Key="Massalin and Pu",
		Title="A Lock-Free Multiprocessor {OS} Kernel",
		Institution="Department of Computer Science,
			Columbia University",
		Number="CUCS-005-91",
		Year="1991", Month="February"
	   )

@Article(FineGrainSched,
		Author="Massalin, H. and Pu, C.",
		Key="Massalin and Pu",
		Title="Fine-Grain Adaptive Scheduling using Feedback",
		Journal="Computing Systems",
		Publisher="University of California Press",
		Year="1990", Month="Winter",
		Volume=3, Number=1,
		Pages="139-173",
		Note="Special Issue on selected papers from the
			Workshop on Experiences in Building
			Distributed Systems, Florida, October 1989"		
	    )

@InProceedings(SynthesisImple,
		Author="Massalin, H. and Pu, C.",
		Key="Massalin and Pu",
		Title="Threads and Input/Output in the {Synthesis} Kernel",
		BookTitle="Proceedings of the Twelfth Symposium on 
			Operating Systems Principles",
		Address="Arizona",
		Pages="191-201",
		Year="1989", Month="December"
	    )

@Article(Synthesis,
		Title="The {Synthesis} Kernel",
		Author = "Pu, C. and Massalin, H. and Ioannidis, J.",
		Journal= "Computing Systems",
		Publisher="University of California Press",
		Key="Pu et al.",
		Year="1988", Month="Winter",
		Volume=1, Number=1,
		Pages="11-32"
	)
From: daves@comp.lancs.ac.uk (Dave Stow)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 10 Apr 92 12:47:52 GMT
Organization: Department of Computing at Lancaster University, UK.
Originator: osr@ftp

In article <32422@darkstar.ucsc.edu> mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) writes:
>>>   - Microkernels are the way to go
>
>>Yeah - Microkernels seem to be a good way [.. etc ..]
>
>	The thing to remember about microkernels is that it's just a
> shuffling around of services. 
> It's not as if going to a microkernel ...
>                          can somehow magically make the system get
> the same amount of work done with less effort. On the contrary.

I disagree. One of the points of moving operations to user-space is
that to do them there does not require a kernel trap and subsequent
crossing of protection boundaries. Doing kernel traps requires a not
insignificant amount of processor time, and so keeping operations
in the user-space saves 'effort'.

Performing operations in user space is _inherently_ faster than switching
to kernel space and doing them.

-Dave Stow
daves@comp.lancs.ac.uk

Views expressed are mine. But then, who else would express them?
From: jyl@burgess.Eng.Sun.COM (Jacob Levy)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 17:10:36 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Originator: osr@ftp

[About languages for distributed programming, actually]

While I believe this is not (yet) generally "common wisdom", I
believe that we need new languages in order to better express the
inherent concurrency of a program. The model one should program
to is distributed virtual shared memory, with dynamic(*) data
flow synchronization. The challenge of a programming language is
to allow expression of the maximal degree of concurrency
available in an algorithm (as implied by constraints of data
availability).  The challenge of a runtime system for such a
language is to allow a semantically faithfull execution of the
program while making the best choice of what parts to execute in
parallel or remotely.  Thus, a programmer should not be concerned
with putting a communication structure into his/her program,
since that makes the program less portable and less efficient
when moved to another distributed configuration.

(*) Dynamic data flow is different from traditional data flow in
that the latter specifies the data flow network statically in the
program, while in dynamic data flow programs, data communication
can contain embedded data flow relationships.

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.

--JYL
From: mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.os.research
Subject: microkernel layers (was Re: A challenge)
Date: 11 Apr 92 19:14:17 GMT
Article-I.D.: darkstar.32686
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Originator: osr@ftp

wkt@rodos1.adfa.oz.au (Warren Toomey) writes:
>> 1. Microkernels are the way to go.
>
>Very much agreed. Putting as much hardware/dependent code in one layer
>make the whole thing easier to port, and gives the OS proper an abstract
>machine to support.

	Putting hardware dependent code in one layer is generally good
practice in programming any application.

	I utterly fail to see why this is a revelation that applies only
to microkernels! This group has been graced with several postings all
touting microkernels as the way to achieve portability - all ignoring
the fact that that's simply an axiom of portable programming and can
apply to monolithic kernels as well.

	Since we're doing challenges, I'd like someone to explain to
me why a microkernel architecture is any more portable than a monolithic
kernel that has been designed to be modular, with test-racks that permit
separate components to be tested in isolation. I just don't see the
difference. Either I'm stupid, and I'm missing something, or the
main justification I keep hearing for microkernels (portability) is
a bogon.

mjr.

[I don't have an operating system axe to grind. I'm not biassed on this
topic because I've written a monolithic kernel. I'm just sick of people
selling microkernels as THE WAY TO GO because they can do something ANY
well-designed software can do.]
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 11 Apr 92 10:22:56 GMT
Article-I.D.: darkstar.32682
Organization: University of Chicago CILS
Originator: osr@ftp

In article <32546@darkstar.ucsc.edu> daves@comp.lancs.ac.uk (Dave Stow) writes:
|Performing operations in user space is _inherently_ faster than switching
|to kernel space and doing them.

But isn't STAYING in kernel space and doing them faster still? Only
people who really INSIST on coding in assembler (or C or Pascal or
FORTRAN, of course) should be forced to pay that penalty. ;-)
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.os.research
From: usenix!carolyn@uunet.UU.NET (Carolyn Carr)
Subject: USENIX Workshop on Micro-Kernels and Other Kernel Architectures
Organization: Usenix Association Office, Berkeley
Date: Thu, 16 Apr 1992 17:02:18 GMT



PLEASE NOTE:

********************************************************************
*								   *
*  Due to space restrictions, registration for the USENIX Workshop *
*  on Micro-Kernels and Other Kernel Architectures is now closed.  *
*								   *
********************************************************************