NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/wizards/4825

Text File | 1992-11-20 | 5.4 KB | 111 lines

Newsgroups: comp.unix.wizards
Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!swrinde!emory!nntp.msstate.edu!news
From: [e-mail] (Frank Peters)
Subject: Re: Changing the owner of a process
Message-ID: <[e-mail]>
Keywords: process ownership
Sender: [e-mail]
Nntp-Posting-Host: jester.cc.msstate.edu
Organization: Computing Center, Mississippi State University
References: <[e-mail]>
Date: Sat, 21 Nov 1992 05:30:22 GMT
Lines: 97

In article <[e-mail]> [e-mail] (Steve McDowell) says:
:
: I'm sorry if I stepped on your toes;

I don't presume to speac for Chris but I suspect that he was reacting
to yet another instance of a common USENET situation.  Expert A
explains politely why package X punts in situation Y.  Reader B then
responds and says, in effect, "Thats silly!  You should just twiddle
this and restructure that and keep on going!" where it is pretty
obvious that B either hasn't thought through the implications of
his/her idea or is ignoring the fact that other peoples needs aren't
identical to his/her own.

If you had posted "wouldn't it work if you did foo?" or "why couldn't
you just do foo?" or "I think it would probably be better to do foo." I
suspect you would have gotten a very different response.  But you
didn't.  You just told him why what he was doing was wrong.  Contained
in that was the implicit assumption that either he didn't know what he
was doing or that his needs are exactly identical to your own.  You, in
effect, said "thats silly! You should just do foo and keep on going!"
An attitude that certainly justifies at least a slightly testy
response.

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

But Chris is working "in the lab" and was describing the behavior of
the systems there...as more or less an illustration of the fact that it
is dangerous to assume that you can just twiddle with a kernel
datastructure at will.  Kernel data structures are where the operating
system stores its view of the world.  Twiddling with those structures
behind its back is likely to make the system psychotic if you aren't
careful.

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

Hmmm...I question your reasoning.  You seem to be operationg under the
assumption that the operating system should just know that nothing
really bad is wrong.

In the real world such a gross inconsistency in a kernel data structure
is probably either (a) a sign of a MAJOR operating system bug or (b) a
sign of a MAJOR hardware fault or (c) a sign of a very subtle security
breach (remember, we are talking about changing the ownership of
processes).  In any of these situations it is very likely that just
adjusting the OS' view of reality and continuing on risks problems
significantly worse than a bit of downtime.

You have critical applications in an environment in which system uptime
is more important than system integrity or system security?  You want
the system to continue to process your data in the face of what (to
the system) looks like a major system consistency failure?

I can certainly imagine such critical applications but I don't think
they are common...and they probably require specially written fault
tolerant systems anyway.

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

Basically irrelevant.  He pointed out the problem that the suggested
solution would cause on one implementation.  You didn't argue that
his solution was inappropriate for your situation.  You contended
that it was wrong in absolute terms.

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

That's hardly Chris' fault.  He designs systems for his purposes.
Arguing that he shouldn't design systems to meet his needs because
someone is going to then take that system and use it to meet other
needs without appropriate modifications is just a bit selfish.

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

If Chris learned anything from it or got any personal satisfaction out of
it then it has turned a profit for somebody.
--
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: [e-mail]  -  Phone: [phone]  -  FAX: [phone]