On 2016-07-16, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2016-07-16 15:09:20 +0000, Simon Clubley said:
>
>> On 2016-07-14, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>>>
>>> Coordinating with the device driver code is a fair part of this. The
>>> driver needs to be told (and routines in the driver written to) gather
>>> up and flush all the pending I/O requests back to the requesting code.
>>
>> You stall any driver unloading until the reference count on the device
>> is zero. You could also optionally use a flag on the unload command to
>> allow existing requests to complete but deny any new requests after the
>> unload command was issued.
>
> Which does little for IRPs initiated by the driver itself (drivers can
> autonomously communicate with their associated devices and with other
> device drivers).
>
Why not ?
You could have a mechanism to reject the queueing of new IRPs in the
same way as you could reject user level I/Os and you should have a
mechanism to tell the other kernel components to rundown the existing
I/O requests in a controlled manner.
Conceptually, it's exactly the same thing regardless of whether
another kernel component issues the I/O request or whether a user
application issues the I/O request.
Also, any new unload mechanism could still be used for all the drivers
out there which don't have any special hardware requirements which stop
them from being safely unloaded. Notice I said hardware requirements
BTW; an IRP which cannot be cancelled purely because the software
design does not allow it is a flaw in that software and not in any
unload mechanism.
> Drivers can allocate system or device memory or other resources for use
> as buffers or mapping windows or caches, and those do not necessarily
> exist at known and fixed offsets in the UCB.
>
And that's exactly the kind of thing you take care of during the
driver's unload routine.
> There are any number of other details that can arise within some
> drivers. Not all device I/O activity involves user I/O channels.
>
> Any unload request has to notify the driver to request the clean up.
>
Exactly. Having a driver rundown routine within the driver itself is
a perfectly normal thing to have when your OS supports unloadable
drivers.
>> This is how Linux works; check out the man page for rmmod.
>
> OpenVMS is not Linux.
>
No, it most certainly is not.
At the user visible level, VMS has got some _really_ nice features
which don't exist elsewhere, but down inside the privileged guts
of the code, it's clearly a tightly bound monolithic mess of
intertwined code with interdependencies which simply shouldn't exist
to the extent that they do in today's world.
I can understand why it was done that way when the design was
implemented in the 1970s with the limited hardware of the day (when
you had to have a really good reason to implement various levels of
potentially resource consuming abstractions) and when portability
simply was not a concern (because VMS was designed to take full
advantage of the VAX architecture).
I also actually think the decisions taken at the time in the 1970s were
fully valid for the time because they resulted in a _very_ solidly
designed product for the hardware of the time but here in the 21st
century that mess of interdependencies is now a major problem.
For example, it's now been over 18 months since the VMS port to x86-64
was announced.
I appreciate the hard work that VSI are doing (and I sincerely hope
they succeed; I look forward to VMS on x86-64 and even maybe other
architectures), but by now a port of Linux (or any other OS implemented
with portability in mind) to a new architecture would almost certainly
have had some early testing versions out of the door and into the
hands of customers.
And as you yourself point out at every opportunity you can, VMS is now
competing in today's world, not the world of the 1970s/1980s/1990s.