"Greg A. Woods" wrote:

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

Indeed. :)


> Whether or not it is worth re-engineering the driver API for Unix at
> this late date is highly questionable.

My proposal was NOT to change the existing interface, but to add one
more method that is called on every close.  I wanted to keep the old
methods around.  My proposal needs a little updating though, see another post.


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

It would be totally compatible.  All old drivers would work.  Only the ones that
want the new functionality would use it.

--

        -- Lennart