[ On Monday, October 16, 2000 at 06:16:45 (+0200), Thorbjorn Jemander wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> I'm neither a driver nor a kernel expert, but other systems have the
> symmetry you propose (or not propose - given the amount of work).

Indeed Unix has open()/close() symmetry -- just not in the driver API.
The symmetry is at the system call level and in the upper kernel layers
only since it is not needed at the hardware level.

Right now the Unix driver API uses the open() call for both first-time
hardware initialisation and for per-descriptor checks and
initialisation, but the close() call is used only for final hardware
shutdown/disconnection/etc.

It probably would have been better to have a separate init() and open()
driver interface, and to have called what is now close() uninit()
instead.  This way the uper layers of the kernel could call init() once
on the first open(2) and to call uninit() once after the last close(2).

[Where "(2)" indicates the system call and "()" indicates the driver API]

This would turn Lennart's proposal into one of adding a driver close()
routine (to be called from every close(2)), which would be a much
different kettle of fish all together.

Whether or not it is worth re-engineering the driver API for Unix at
this late date is highly questionable.  I would think that it is not
worth the effor since except for the odd strange corner cases mentioned
so far I doubt there's really anything that would be solved by doing so
(which cannot now be solved in other more practical ways).  In the mean
time you'd end up with a very unique system that would require more
effort in porting and supporting drivers so unless the API were
arbitrarily changed in all places to make it totally incompatible it
would most certainly lead to many errors by people very experienced with
Unix internals but learning this new API for the first time.

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