Subject: Re: Time to fix a 25 year old misdesign
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 10/15/2000 13:35:22
[ On Sunday, October 15, 2000 at 17:47:22 (+0200), Lennart Augustsson wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> Well, sometimes you want to view it that way, but sometimes you just want
> to view it as a single device. And that goes even more for USB ugen devices.
Sure, that's fine. However that doesn't change the design flaw in the
audio driver. A single all-encompassing /dev file that's exclusively
avaiable to one process at a time is fine for processes that perform all
management of all functions of the device.
> I claim that the design is wrong regardless of how you view it. The reason is
> the lack of symmetry. There should be a match between open() and close().
Nope -- there's no lack of symmetry because there's no symmetry intended!
You're confusing user-land conventions with kernel-level driver APIs.
The kernel calls the device close() routine only once when it knows the
device is no longer in use and can therefore be shut down in whatever
manner the driver so chooses as required by the hardware it is
controlling.
The kernel already handles the symmetry at a higher level. See for
example the algorithm described on p.319 of Bach(*).
Note that in the case of a block device it is impossible to mandate
open()/close() symmetry at the driver level! Character devices which
allow multiple simultaneous opens simply keep a flag so as to remember
if they've already been opened and thus to avoid doing unnecessary or
troublesome re-initialisation of the hardware.
You should read some of the old papers again, and maybe stare at
sys/ic/com.c:comopen() a bit....
> If you also claim that dev_open() should be called only once because
> it performs initialization that only needs to be done when the device is first
> opened, then I'd buy your argument.
The device open() routine may indeed perform device initialisation,
assuming it needs to. However it also has the job of mediating access
to the device and can control exlusive access, or check permissions for
privileged devices, etc.
> Well, I don't think we have the option of changing that. There's too much
> software out there that expects the current design. So you just suggest
> replacing one problem with a worse problem. :)
Why not? Keep the old /dev/audio with the broken design and design a
new interface with the correct semantics using multiple /dev nodes. New
programs can benefit from the correct design and old programs will
continue to suffer from brain damage in the old design.
(*) The Design of the Unix Operating System, M.Bach.
--
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>