From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 2-SEP-1992 10:36:09.61 To: uunet!"macro32%wkuvx1.bitnet@cunyvm.cuny.edu" CC: Subj: RE: moving DDT for CDdriver etc. 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 DDT winds up in MY UCB, and CDdriver will find the DDT 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-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. 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 DDT copy in the area labelled "ucb$a_victimDDT" 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 functab functab myswitch, functab mypatch1, functab mypatch2, ... functab mypatchn, functab to_orig, 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