home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1259 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  4.2 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!mvb.saic.com!macro32
  2. From: raxco!galaxy.dnet!gleeve@uunet.UU.NET
  3. Newsgroups: vmsnet.internals
  4. Subject: RE: moving DDT for CDdriver etc.
  5. Message-ID: <9209021345.AA08910@relay1.UU.NET>
  6. Date: Wed, 2 Sep 92 09:18:16 -0400
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 83
  10.  
  11. I don't know of anything that would be harmed by moving the DDT for
  12. the victim disk to the UCB of a CDdriver caching driver. However
  13. I would like to make a plea for extensibility.
  14.  
  15.    The idea of pointing ucb$l_ddt at a DDT that physically resides
  16. in a UCB of some other device like CDdriver is a wonderful way to
  17. make finding the corresponding device fast and reliable.
  18.    It suffers from the disadvantage that it works for ONE driver
  19. only as proposed. That is, if I come along and try to steal the
  20. DDT again and happen to use the original driver's UCB$L_DDT
  21. link, the new DDB winds up in MY UCB, and CDdriver will find the
  22. DDB in the wrong place.
  23.    What I would suggest is adoption and publication of some standard
  24. that is extensible. It will involve some chaining, but will not
  25. break the first time a second app tries to use it.
  26.  
  27.    The notion is to produce a UCB extension that looks like this:
  28.  
  29.         .long   ident-pattern
  30.         .long   previous-DDB-address
  31. ucb$a_victimddb:
  32.         .blkl   nnnn    ;however long this needs to be, look it up
  33.  
  34.    With such a standard in force, if I find the DDB from ucb$l_ddb
  35. of the victim device, I can check ident-pattern against my
  36. own program's pattern, and if it matches I just go ahead and use
  37. offsets from there to find my driver's UCB and thus its data
  38. (e.g. the CDdriver UCB). If it does not match, I chain using
  39. the previous-DDB-address and keep looking for my pattern, and
  40. when I find it (in usually one or two tries at most), I have
  41. found my UCB and can go on from there.
  42.    The pattern choice is arbitrary, and I have no great objections
  43. to making it two longs, but I think one is enough by prejudice.
  44.    It is necessary of course that this chain never be removed
  45. or broken once established, though the contents of the DDB copy
  46. in the area labelled "ucb$a_victimddb" above could of course
  47. be altered if one wanted to turn off a program. However it is
  48. essential that the original device (e.g. the disk being cached
  49. by cddriver) NOT just have its' ucb$l_ddt replaced by the
  50. original value if this is done, since someone else may have
  51. grabbed the pointer and be using it for other purposes.
  52.    I would suggest a similar strategy be used for stealing
  53. FDT table bits also. These can be made to coexist rather nicely
  54. if one has a structure somewhat along these lines for FDT routines
  55. to be added to a driver's FDT chain.
  56.  
  57.         .long   ident-pattern; unique for each application
  58.         .long   old-fdt-table-address-from-before-patch
  59. newfdt: functab <mask for disk legal functions>
  60.         functab <mask for disk buffered functions>
  61.         functab myswitch,<mask of all 1's>
  62.         functab mypatch1,<mask>
  63.         functab mypatch2,<mask>
  64.         ...
  65.         functab mypatchn,<mask>
  66.         functab to_orig,<mask of all 1's>
  67. myswitch:
  68.         tstl    myonoff
  69.         bneq    1$
  70.         rsb
  71. 1$:     addl2   #<12*<# of patch FDT routines I added>>,r8
  72.         rsb
  73. to_orig:
  74.         movl    newfdt-4,r8      ;point to original FDT point
  75.         addl2   #<16-12>,r8      ;pass the 2 entry masks
  76.                                  ;back up since sysqioreq adds 12
  77.         rsb                      ;off to the previous FDT routines.
  78. myonoff: .long   0       ;my global switch, can be before or
  79.                          ;after the rest, doesn't matter since only
  80.                          ;my code knows about it.
  81.  
  82.         This scheme too will let multiple independent programs get
  83. along without clobbering one another (unless by chance their
  84. identifiers collide). One can imagine ways to pick identifiers
  85. that will seldom collide...RAD50 encoding of programmer's initials
  86. for one word and binary encoding of some date (-1900) that is
  87. significant to that person in the other word, for instance. Other
  88. schemes can be tried as desired.
  89.    What say the rest of the forum?
  90. Glenn Everhart
  91. Everhart@Raxco.com
  92. 215 358 5875
  93.  
  94.