From:	STAR::EVERHART     "Glenn C. Everhart 603 881 1497"  4-APR-1997 14:30:06.68
To:	COUGHLAN
CC:	EVERHART
Subj:	FYI, letter I sent to Mark Difabio of free advice.

Mark -
If you reply to Ben Rosenberg you want to be careful which stuff in my
letter gets quoted. I believe the right answer for the QAR is to
point out that:
1. Digital has not, for at least 20 years, promised that internal interfaces
        will remain unchanged.
2. The driver interface is documented and followed, but what happens inside
        a driver, and in particular what happens between a driver and its
        own UCBs, is mostly internal to the driver. In particular the way
        it processes IRPs is an internal choice.
3. The problems that this guy is having are due to his trying to intercept
        I/O by catching it at the driver start_io entry. There is no
        guarantee that this will see all IRPs, and in fact the driver
        writing documentation points out that drivers that are multithreaded
        maintain their own queues, and are complex.
4. His assumption that the old, non-threaded driver behavior would remain
        indefinitely was incorrect.
5. While some work is going on which may result in a way to again know that
        a driver start_io entry will see all I/Os, this is not a foregone
        conclusion. Also, it is likely that a particular format for
        any such interception would be required in order not to cause
        random system crashes or loss. Random I/O interception in the MSDOS
        world has caused endless problems for users, and these problems
        have existed in VMS where different third party vendors have
        made incompatible changes to VMS data structures. Any interception
        risks this.
6. The DKdriver behavior change was made to prevent a particularly nasty
        problem which would cause system crashing if not fixed. Changes to
        use the old behavior were rejected at the time this was done
        because of the system crashes and because solutions to the system
        crashing that did not impact performance adversely were not
        found at the time. DKdriver's job is to do I/O as fast as possible,
        and Digital's caching, shadowing, and so forth all continue to work
        correctly with it.
7. Should a way be found to restore the pre-threading driver behavior
        without impacting performance, it will be published.



Pass such stuff by Tom C., I'd advise, to ensure you step on no toes.
Some of the detail in my letter was meant to impress upon R. the
severity of the problem, but doesn't belong in anything that gets
readable by others. Still, we need to ensure that Digital doesn't
get sucked into an obligation to maintain internal interfaces by
anything we say. Legal may even be well advised to get an OK from.
New mail on node HELENA from STAR::CAMUSO "Whoso mocketh the poor reproacheth hi
s Maker  04-Apr-1997 1358 -0500" (14:06:03)
anything we say. Legal may even be well advised to get an OK from.

We may want to reply with some more positive stuff too, and I
have no grief with that. But just how positive we can be is I suspect
politically AND LEGALLY touchy. You'd do well to handle anything
official here with kid gloves; let someone route it to get legal
OK if you need to...

The foregoing is my free advice, btw...I'm not a Digital official...
but the problem here is in this 3rd party code making assumptions
that were false. Unlike the prior situation Rosenberg has mentioned
to me with DK reordering I/O, this change was made for performance
reasons and to prevent crashes; it's not something that can trivially
be fixed. It's not a bug, but a change in DKdriver internal design.
(Also, be aware the product is I think in part a competitor against
Digital's volume shadowing product.)

Glenn Everhart