🚀 go-pugleaf

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.

   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.
   What I would suggest is adoption and publication of some standard
that is extensible. 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-DDB-address
ucb$a_victimddb:
        .blkl   nnnn    ;however long this needs to be, look it up

   With such a standard in force, if I find the DDB from ucb$l_ddb
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-DDB-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.
   The pattern choice is arbitrary, and I have no great objections
to making it two longs, but I think one is enough by prejudice.
   It is necessary of course that this chain never be removed
or broken once established, though the contents of the DDB copy
in the area labelled "ucb$a_victimddb" above could of course
be altered if one wanted to turn off a program. 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.
   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.

        .long   ident-pattern; unique for each application
        .long   old-fdt-table-address-from-before-patch
newfdt: functab <mask for disk legal functions>
        functab <mask for disk buffered functions>
        functab myswitch,<mask of all 1's>
        functab mypatch1,<mask>
        functab mypatch2,<mask>
        ...
        functab mypatchn,<mask>
        functab to_orig,<mask of all 1's>
myswitch:
        tstl    myonoff
        bneq    1$
        rsb
1$:     addl2   #<12*<# of patch FDT routines I added>>,r8
        rsb
to_orig:
        movl    newfdt-4,r8      ;point to original FDT point
        addl2   #<16-12>,r8      ;pass the 2 entry masks
                                 ;back up since sysqioreq adds 12
        rsb                      ;off to the previous FDT routines.
myonoff: .long   0       ;my global switch, can be before or
                         ;after the rest, doesn't matter since only
                         ;my code knows about it.

        This scheme too will let multiple independent programs get
along without clobbering one another (unless by chance their
identifiers collide). One can imagine ways to pick identifiers
that will seldom collide...RAD50 encoding of programmer's initials
for one word and binary encoding of some date (-1900) that is
significant to that person in the other word, for instance. Other
schemes can be tried as desired.
   What say the rest of the forum?
Glenn Everhart
Everhart@Raxco.com
215 358 5875