[ On Wednesday, October 18, 2000 at 09:09:41 (+0200), Lennart Augustsson wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> I don't think so.  It show something that's hard to get right in the
> current design.

Ah, no, it's not hard to get right because of the current design -- it's
hard to get right because you're not supposed to do it in the first place!

Recording a reference to a proc table entry in the driver is wrong from
the get go and must not be done because that reference can become
invalid without the driver's knowledge.  Adding file descriptor
reference counts to the driver alone will not fix this problem either --
the only safe place to store the proc table reference is in the file
descriptor table of the proc entry itself.  (Though if psignal() had
some way of safely determining the validity of a "struct proc *" before
trying to use it then in reality it would do little harm in the specific
case of SIGIO alone.)

> > A colleague suggested just forcing the device to be completely closed
> > before allowing it to open again.
> 
> That's simply not good enough for all devices.  I want to use this for
> wsmux as well, and in the wsmux case requiring this would mean that
> you could not switch from a virtual console running X to another and
> then back (since X closes the mouse when you switch out and opens
> it when you switch back in.)

I think you need to write down and post the requirements for wsmux.  I
suspect there are much better ways of doing that, but without
understanding the base requirements I cannot begin to suggest a better
alternative.

Remember that the hardware driver's job on open and close is only to
initialise the hardware on first open (eg. raise DTR and DCD) and shut
it down on last open (eg. drop DTR and DCD).  It should not be concerned
with intermediate opens and closes while some other process already has
it open.  It really shouldn't even care how many processes have it
open.  If the "user" starts several processes that open the same device
then it's the user's responsibility to ensure that all of those
processes co-operate properly.  The hardware driver must not try to
force assumptions on the upper layers.

Think about this for a bit:

	(stty 9600 crtsdts ; sleep 30000) < /dev/tty00 &
	cat < /dev/tty00 > input.data &
	cat > /dev/tty00 < output.data &

Your proposal to add (even optional) file descriptor reference counts to
the hardware driver API is not valid.  The hardware drivers have no
business knowing or caring about this information because doing so will
force assumptions on the upper layers.  If I want to open a device node
with a hundred processes and then write 1/100'th of a stream from each
in succession then that's my business -- the hardware driver must not
prevent this.

> Feel free to improve it.  An alternative to NAS and similar programs
> is to allow multiple opens of the audio device and let the kernel mix
> the audio streams.

That would work just fine too (though I'n not sure "mix" is the right
verb there, at least not in the sense used by most audio techs).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>