NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/vmsnet/internal/1297

Internet Message Format | 1992-09-08 | 7.3 KB

Path: sparky!uunet!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
From: "(Jon Pinkley, Westinghouse [phone] x1335)"
Newsgroups: vmsnet.internals
Subject: RE: moving DDT for CDdriver etc.
Message-ID: <[e-mail]>
Date: Tue, 8 Sep 92 00:10:49 -0400
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List
Lines: 155

Glenn Everhart, [e-mail], wrote on 2-Sep-1992, responding
my article "UCB$L_DDT != DDB$L_DDT".

>I don't know of anything that would be harmed by moving the DDT for
>the victim disk to the UCB of a CDdriver caching driver. However
>I would like to make a plea for extensibility.

That's a good goal.

>   The idea of pointing ucb$l_ddt at a DDT that physically resides
>in a UCB of some other device like CDdriver is a wonderful way to
>make finding the corresponding device fast and reliable.
>   It suffers from the disadvantage that it works for ONE driver
>only as proposed. That is, if I come along and try to steal the
>DDT again and happen to use the original driver's UCB$L_DDT
>link, the new DDB winds up in MY UCB, and CDdriver will find the
>DDB in the wrong place.

You lost me there with that subtle context switch.  I assume you
meant DDT where you wrote DDB.  I have taken the liberty to change
the DDB's to DDT's in the rest of the article.  I'm sure you will
let me know if you really did mean DDB.  However, my original
article talked about copying the DDT (not the DDB) to the UCB.

    NOTE: the following lines preceeded by "!" were edited to what
          I think Glenn meant.

!link, the new DDT winds up in MY UCB, and CDdriver will find the
!DDT in the wrong place.

Yes, this would indeed cause problems.

>   What I would suggest is adoption and publication of some standard
>that is extensible.

This is a good idea.  I think we should first state the goals of the
standard, and what it would affect (i.e. what has to change).

Perhaps DEC can incorporate something into the new driver spec for
ALPHA.  If you were able to design this from a clean slate, what
goals would you have?

>                      It will involve some chaining, but will not
>break the first time a second app tries to use it.
>
>   The notion is to produce a UCB extension that looks like this:
>
>        .long   ident-pattern
!        .long   previous-DDT-address
>ucb$a_victimddt:
>        .blkl   nnnn    ;however long this needs to be, look it up
>
!   With such a standard in force, if I find the DDT from ucb$l_ddt
>of the victim device, I can check ident-pattern against my
>own program's pattern, and if it matches I just go ahead and use
>offsets from there to find my driver's UCB and thus its data
>(e.g. the CDdriver UCB). If it does not match, I chain using
!the previous-DDT-address and keep looking for my pattern, and
>when I find it (in usually one or two tries at most), I have
>found my UCB and can go on from there.

This all works fine, as long as everyone plays by the same rules.
Unfortunately, any standard we agree on won't be enforceable.
It's easy to detect that things are ok (with high probability) if
the DDT is in your UCB, but if you don't find your signature (ident
pattern), it isn't as easy to determine that it is safe to follow
the previous-DDT-address.  An access violation in kernel mode at
elevated IPL is not very forgiving.  The other possibility is that
the chain has a loop.  Then we wouldn't crash, but we would be in a
loop running at fork ipl, which in my opinion is even worse than a
crash, since it requires manual intervention to remedy the
situation.  Yes, we could define a max-hop count.  This still
doesn't solve the problem, it just lets us detect loops in
previous-DDT-address chains.  (My original proposal didn't address
these issues at all.)

>   The pattern choice is arbitrary, and I have no great objections
>to making it two longs, but I think one is enough by prejudice.

If you want it unique per driver, you could put the address of your
intercept driver's DPT there.  The nice thing about using the DPT
address is that this will stand out in SDA listings as the driver
name;  i.e. if you do a show stack it will display something like:

                811d0648  811d0510      CDDRIVER

>   It is necessary of course that this chain never be removed
!or broken once established, though the contents of the DDT copy
!in the area labelled "ucb$a_victimddt" above could of course
>be altered if one wanted to turn off a program.

I think this restriction is unnecessary.  This restriction would not
allow for deletion or reuse of an intercept driver UCB.  What is
necessary is that everyone synchronize and leave things in a defined
state.  The standard should specify what can and can't be done, how
things will be coordinated, etc.

>                                                 However it is
>essential that the original device (e.g. the disk being cached
>by cddriver) NOT just have its' ucb$l_ddt replaced by the
>original value if this is done, since someone else may have
>grabbed the pointer and be using it for other purposes.

Agreed.

What is needed is a way for intercept drivers to repair things in a
consistent way.  What if all intercept drivers had a predefined
place for other intercept drivers to place their DDT address into,
then it would be possible to remove an intercept driver's UCB from
the DDT chain.

        .long   ident-pattern        ; unique to driver that owns this ucb
        .long   intercept-DDT-address; This is modified by another intercept
                                     ; driver that intercepts the victim UCB
                                     ; after we do.  This allows us to find
                                     ; the our interceptor's DDT.
        .long   previous-DDT-address ; where to find the next startio addr
        .long   intercept-signature   ; same for all intercept drivers
ucb$a_victimddt:
        .blkl   ddt$k_length         ; note this changed in V5.5

Two things have been added to Glenn's suggestion.

First is a signature that would have to be unique to all intercept
drivers.  This would allow intercept drivers to have a better
indication that it is safe to follow the previous-DDT-address.

Second is an intercept-DDT-address pointer that is modified by
a by an intercept driver when it intercepts a device that has
already been intercepted.  This allows an intercept driver's UCB to
be removed from the DDT chain, by modifying the previous-DDT-address
of the DDT extension pointed to by intercept-DDT-address, and if the
previous-DDT-address is not the original driver's DDT (as indicated
by the victim UCB's ucb$l_ddb -> ddb$l_ddt chain), then modifying
the intercept-DDT-address of the DDT extension pointed to by
previous-DDT-address.  All of this should be done while holding the
fork lock specified by the victim UCB.

What else besides an intercept driver may grab the ucb$l_ddt pointer
and be "using it for other purposes."

>   I would suggest a similar strategy be used for stealing
>FDT table bits also. These can be made to coexist rather nicely
>if one has a structure somewhat along these lines for FDT routines
>to be added to a driver's FDT chain.

Good idea.  I haven't thought about the ramifications of removing
the DDT block from the chain here.

>   What say the rest of the forum?
>Glenn Everhart
>[e-mail]
>215 358 5875

Jon Pinkley [e-mail]  ...uunet!tron!clevax!jon [phone] x1335