[ On Tuesday, October 17, 2000 at 23:16:33 (+0200), Lennart Augustsson wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> I repeat again: I'm not interested in SIGIO and I don't know if Linux
> emulation requires it.

OK, then it was a really bad example.  However the audio driver is
currently one of the abusers of SIGIO.

>  But Linux emulation does seem to require that
> you can open a device independently for read and write.  This cannot
> be implemented with the current device driver API.

Why not?

A colleague suggested just forcing the device to be completely closed
before allowing it to open again.  I.e. allow one exclusive open for
read and one exclusive open for write (or one exlusive open for
simultaneous read and write) and then let the driver close() routine
clear these flags when the last process exits.  The only drawback here
is that if an unrelated process holds the device open then it may be
necessary for that process to provide a way for some other process to
cause it to close and re-open the device.  Supposedly at least one audio
application already includes such a feature though so maybe it's not a
big problem.

The other solution is of course to split the driver up so that there are
additional minor devices -- such as one that handles reads
(eg. "/dev/microphone") and one that handles writes
(eg. "/dev/speaker").  The Linux emulation can simply map the
open("/dev/audio", O_RDONLY) into an open("/dev/microphone") and
conversely an open("/dev/audio", O_WRONLY) into open("/dev/speaker").
An open with O_RDRW would just map straight through.

Conversely there's really no reason why you can't just allow multiple
opens (especially since it's impossible anyway for the driver to ensure
that only one file descriptor ever refers to the device at a time) and
thus delegate the problem up to user level.  Any process that wants to
take over exclusive control of the device can simply open it with
O_EXLOCK and be happy when it succeeds.  Don't forget that normal unix
file permissions can also be used to make sure that unauthorised users
can't grab exclusive access to a device too.

Fundamentally I don't see why the audio driver should try to force
exclusive opens anyway -- if the user does something stupid and sends
two incompatible streams to the same driver then a horrible noise will
spew from the speakers and the user will learn his lesson.  In a truly
sane system something like NAS would be used to mediate access to such
devices, just as the X11 server mediates access to keyboards, mice,
frame buffers, and such.  The current way audio is handled in many
unix-like systems seems very primitive to me (my systems use NAS!).

There's still the option of designing a proper upper layer for audio
services too, though I do wonder just how worthwhile such an effort
would really be.

There are an almost infinite number of specific solutions to this
problem which do not invovle changing a fundamental driver API (even if
only to add new optional calls).

> Being able to open for read and write independently is my reason for
> wanting the redesign.

That's not a sufficient reason to muck with something so fundamental
and would effectively violate the current layering of the kernel.

>  I just brought up SIGIO as an example of another
> thing that is flawed in the current design, and that could be done right
> if the driver was informed of all added and deleted references.

SIGIO should never be done from a hardware driver in the first place so
it's a bogus requirement.

> Well, unfortunately we are stuck with the way devices like audio works
> for backwards compatibility reasons.

Why?  The compatability layers can take care of the mapping and any
other stupidities thought up by those who didn't pay attention to the
unix design in the first place.

> You should have made sure we got it right in the first place. :)

It's never too late to do something right even if it wasn't done right
in the first place.

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