From: mcdowell@exlogcorp.exlog.com (Steve McDowell)
Subject: Re: Changing the owner of a process
Keywords: process ownership
Organization: EXLOG, Inc.
Date: Sat, 21 Nov 92 02:28:33 GMT

In message <27581@dog.ee.lbl.gov>torek@horse.ee.lbl.gov (Chris Torek) writes:
>
> I will make you a deal:  If you do not try to tell us how to do O/S
> research, 

Calm down Chris, there's no need for a personal exchange here. You don't
know me or what my background is, so be very careful before you presume
the wrong things. 

I'm sorry if I stepped on your toes; I didn't realize how close you were
to bsd4.4. But this forum is for the exchange of ideas from whomever 
presumes to present them. The research community really should listen before
flying off the handle and the ideas will continue to flow and that will
be a good thing for everyone. 

> I will not try to tell you how to sell commercial systems.

But you don't understand, I wish you would -- we really do need the help....

> If the counts are goofed up, either the hardware is broken---the 4.4BSD
> development line is not intended to be able to handle this situation,
> although if it recurs predictably we will probably hack around it---or
> (far more likely) there is a bug in the kernel source.  An immediate
> panic gives us a much better chance of finding and repairing the bug
> than a syslog-and-reset.

Or, in the case that my original article was in response to, you have a user
who fancies himself a "system programmer". I'm a big believer in the 
condom approach to end-user computing -- let a user stroke himself all
he wants to but don't let his results impregnate the integrety of my 
operating system. 

In the lab, I agree with you completely. I keep the error correction in my 
own code disabled until very late in the game.  But the code is there, and 
that's my point.

In the real-world, in a critical application, I'd much rather have a 
syslog-and-reset than a panic that's going to have to be called in to a 
support group while the dump sits cluttering up somebody's dasd. If there's
a situation that can be recovered from, then recover. I really don't see
how you can argue against this.

> Commercial vendors are free to replace various panic()s with the
> appropriate recovery code.  For our purposes, recovery is not only
> unnecessary, it is in fact *in*appropriate.

Of course, for your purposes developing an operating system is a means
unto itself. You don't have to worry about irrelevant things like 
"customers" and "applications". I wish I didn't. 
 
I hope that vendors do replace panics where they can. The problem becomes that 
commericial vendors don't always take the time to get it right. Too many vendors
simply port the code they get from USL or CSRG or CMU to get compatable 
functionality; that makes it simple to integrate new releases and keeps the 
lead time to market short. That's not the research community's problem, that's 
a problem for everyone else. 

This is all moot, though. From what I understand, not too many commercial
vendors are interested in porting bsd4.4 and selling the result. I hope my
information on this is wrong because I'd hate to see all that hard work not 
turn a profit for somebody. 

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   
Newsgroups: comp.unix.wizards