Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Keywords: user interface Unix filesystem
Message-ID: <5297@auspex.auspex.com>
Date: 16 Jan 91 19:09:42 GMT
References: <1628@lee.SEAS.UCLA.EDU> <5259@auspex.auspex.com> <1641@lee.SEAS.UCLA.EDU>
Organization: Auspex Systems, Santa Clara
Lines: 92

>Right.  But the issue of which signal it's catching, and exactly what
>mode bit is being used for which signal, etc., is an implementation detail.  
>Mainly, I was trying to attack the user interface problem; the reasoning
>was that it would simplify things to unify the user interface for dealing 
>with all system resources.

I think the reasoning is fundamentally flawed, because I don't think it
*does* unify the user interface.

>That I won't be able to solve all of the 
>implementation problems right here and now doesn't mean that one could
>not develop an attractive and practical solution.

But it might mean that the solution being proposed can't be made
attractive and practical due to fundamental flaws; the appearance of
problems that can't be solved right here and now might be due to those
flaws.

>You could present separate bits (not necessarily rwxrwx... but perhaps
>something like prakqt21) for the different signals.

But then you haven't unified the user interface; those bits don't apply
at all to plain files!

>But if we need more bits, we get more bits!  Are you worried about
>overhead,

No.

>filesystem incompatibility?

Yes - I'm worried that the objects you're constructing now end up
looking sufficiently different from files that you really haven't
unified the user interface....

>I think those issues can be contained.

I don't; you'll have to demonstrate a way of containing them before I
believe they can be contained.

>Whether or not it turns out to be silly depends on the implementation.
>Yes, it could turn out to be rather tacky if you desire.  Some things,
>like the date of creation, user name, translate fairly well across 
>boundaries.  Other things can be decided by the user interface that 
>'ls' or lower level routines wish to provide.  Bits are bits.  How you 
>interpret or show what they mean is up to the user interface.  

I suspect *any* implementation that tries to pretend that processes are
*that* much like files will turn out tacky.  Or, to put it another way,
I refuse to believe that it *won't* turn out tacky until somebody
demonstrates a design that doesn't, so if you want to convince me,
you're stuck with solving the problems here and now....

In effect, this seems to resemble using "file" as a base class, and
deriving "process" as a subclass; doing this by overriding some of the
class methods seems to require that you end up with methods of the same
name ("ls", "rm") but with behaviors that don't resemble the behaviors
of those methods in the parent class.  I'd be inclined to add new
methods ("ps", "kill") instead....

If your complaint is that you can't find out which signals a process is
catching/ignoring/blocking, a better solution might be to have "ps" or
some such command be capable of reporting that.

(Note, BTW, that just because a process is catching SIGTERM, that doesn't
mean you should kill it with SIGKILL; in fact, I'd be *more* inclined to
kill it with SIGTERM, because if it's catching SIGTERM, it presumably
has stuff that it wants to clean up before it exits, and if I kill it
with SIGKILL that stuff won't get cleaned up.  The ones you need to kill
with SIGKILL are the ones that:

	1) ignore SIGTERM - which I suspect is an error on their part;
	   they should probably *block* it for a short time, instead, so
	   that the SIGTERM gets to them eventually;

	2) have a bug in their SIGTERM cleanup code, such that it
	   doesn't exit.

Were those problems less common, SIGTERM would be more likely to work,
and I'd probably have no need to care, except in rare cases, whether the
process is catching SIGTERM.)

>>In fact, even the owner-write bit would have a different meaning; the
>>"rm" command is what normally asks before removing a file not writable
>>by the user - the "unlink()" call only cares about the permissions on
>>the *containing directory*.  I suppose you could make "/proc" a sticky
>>directory....
>You could jumble everything into a /proc, and/or have a /proc/user, or 
>~user/proc.

Except that the write permission on the *file* still wouldn't indicate
whether it could be unlinked.