[ On Tuesday, October 17, 2000 at 20:56:31 (+0200), Lennart Augustsson wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> It's not psignal() I'm worrying about.  It was just a general example.
> I want to implement a audio device that can be opened independently
> for read and write, remember.

That's fine.  Psignal(SIGIO) calls are merely the indicator of the
design flaw.  So long as there are no calls to psignal(SIGIO) in the
driver then there can be no problem with signalling the wrong process.

So to achieve this state of nirvana you have to either drop support for
Async-I/O in the audio driver, or promote it up a layer so that it's on
par with sockets and ttys (i.e. where the process (or process group) to
be signalled is recorded in the file descriptor itself (or something it
points to that is freed when it is freed).

There's still a design flaw in SIGIO (and perhaps SIGPOLL on SysVr4,
though to a lesser extent) due to the way any PID can be registered by
any process.  However so long as this flaw remains in the upper layers
then no change to the hardware driver API is necessary to fix it.

> I know you think this design is broken, but I don't.  And it's also something
> we need if we want to have a working Linux emulation.  (That's may not
> be the greatest of reasons, I agree. :)

If Linux emulation requires SIGIO then choose the second option,
otherwise choose the first and get rid of this nasty hack completely.

Adding another subsystem layer ala ttys doesn't mean changing the
user-land API -- it just changes the hardware driver API by providing
call-back functions in a way similar to what line disciplines provide
for serial port drivers.

> I also want to make the ugen device work in a sane way.  And the wsmux.

You need to promote Async-I/O handling up to the layer where it was
designed to be (i.e. where file descriptors are visible).  It is not
something any hardware driver has any business knowing about because by
definition hardware drivers have no business sending SIGIO directly.

Then once that's done it should be a simple matter of providing separate
minor devices for logically separate functionality so that those parts
of the driver which wish to force exclusive access to a single process
and/or its children can do so without interfering with other similar
parts.

Extending file descriptor references down into the hardware drivers is a
nasty hack that doesn't fit the current Unix I/O model.  It might work,
and other systems might do it, but it's not necessary and I think it's
far less elegant.  The driver talks to the hardware on behalf of the
upper layers of the kernel -- it doesn't know anything about "files" and
it most certainly should not be trying to keep track of processes on its
own!

(Maybe we should still have some way for a lower kernel layer, such as a
hardware driver, to prevent descriptor passing, but that's a separate
issue.)

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