Glenn, Thank you for your response. I'm sure I would remember meeting you if I saw you face to face, but I have never been good with names upon first meetings. The reason I never released my generalized intercept driver publicly has more to do with politics with Executive Software than anything else. I did actually complete a fairly involved version for the VAX and did a more subdued version for the AXP. I am certain I could do a more involved version for the AXP as well, but at this point I doubt there would be much need as the VMS market have changed drastically for third party software products. If you would like to discuss my implementation, I would be happy to do so. On the subject of your security product: Send me an email message about your product. I will try to provide some help to you as to how best to get your product marketed. Include a brief description as to what it does and what kind of financial arrangements you are looking for. I hate to see developers with good useful product not be able to make money due to insufficient marketing outlets. On the original subject of DKDRIVER: It makes sense to me that this came up in V6.2 on AXP/VMS since that's where we start to see problems. It disturbs me that DEC does not see the need to release some kind of patch for 6.2, 7.0, & 7.1. It seems inconceivable to me that DEC did not understand the consequences of this change to a very large segment of their customers. Regardless of the solution, the customers of RAXCO, Executive Software, Symark, and EEC will need a patch (a new DKDRIVER or new IO_ROUTINES, or whatever). As I am sure you are aware that customers many times find themselves stuck on a particular VMS version and telling them they have to upgrade to V7.1h or V7.2 is just not practical. The developers of these companies will also need to know how to take advantage of the changes. There are tens of thousands of potentially affected DEC customers. Besides the caching software vendors, there are several other types of products that intercept Start I/O for disk drives. They also would be affected. I have to plead some level of ignorance into the most internal workings of AXP/VMS versus VAX/VMS. However, it seems to me that re-forking the new IRP (as opposed to just calling Start I/O directly) should solve the problem. This should allow the current thread to pop all stack data and the new thread would then restart on the top of the Kernel Stack when the current thread completes. It seems to me that this would be a reasonably simple change to DKDRIVER. If this is feasable, then this would mean that a new DKDRIVER for V6.2, V7.0, and V7.1 could be released and there would be no changes required for any other software. The vendors affected could even ship the updated driver for DEC (if DEC so allowed) to their customers and could make sure that the new driver was installed with their software thus ensuring data integrity for their customers. If there would be a testing problem for DEC to release this as a supported change, the I am sure that each of the caching vendors would be willing to deal with this issue directly by telling their customers that the new DKDRIVER is not supported by DEC until V7.1h. This gives the customer the opportunity to have a solution for the version of VMS they are stuck on or to upgrade to the latest rev if DEC (as opposed to third party) support is an issue. However, while it would be unsupported, DEC should not make it sound to customers like this is a BAD thing to run. They should just make the party line that upgrading to V7.1h is necessary if they need DEC to support the driver. Alternatively the customer can revert back to the supported driver if they have a problem with DKDRIVER that they would like DEC to support. We would even be willing to support this directly with DEC out of the loop if DEC allowed us (outside vendors) the ability to build DKDRIVER ourselves and pointed us towards where to make the changes. Perhaps a changed set of source files could be available as well as the stuff needed to do the build. I am sure that all developers would sign the appropriate non-disclosures. I would be happy to discuss this on the phone with you if you would like. I would also be happy to look at any proposed changes and help with either their impact or even the implementation. I will be in and out of the office during the holidays, but feel free to call if you want. I will be reading my email regularly during the holidays. Sincerely, Rick Cadruvi R&D Performance Group, Inc. 1180 E Patricia #102 Simi Valley, CA 93065 (805)520-4170 (office) (805)520-4173 (direct desk) (805)520-4169 (fax) rick@rdperf.com From: SMTP%"everhart@row.enet.dec.com" 23-DEC-1996 09:21:13.37 To: "rick@rdperf.com"@3049.ENET.dec.com CC: everhart@row.ENET.dec.com Subj: RE: DKDRIVER & Device I/O Intercept Rick - Good to have your address. If you recall (or even if you don't ;-) ) I met you some years ago when you gave a talk at a DECUS symposium on I/O interception, and mentioned you'd donate a template intercept driver to the sigtapes. (Never did get hold of you afterwards, but I wrote my own and put it out instead.) The problem currently is with only DKdriver on alpha, though other Alpha drivers may need something similar. The listings got censored in 6.2 (I got em uncensored for 7.1 finally!) which is when the problem started. Basically the deal is that dkdriver was blowing knl stack when trying to call the driver start-io every time, so it got altered to just loop around internally in start_io to look for more work. There's no ready external place to hook this, and insioq(c) just call the insert IRP entry directly, again with noplace to steal things. exe_std$insert_irp (spellinf from memory) only needs a queue header address and an element address, making it hard to use the fact that R5 usually points to the victim UCB at the call for anything useful. I'm working up some plans for a fixup, and have actual test code running that alters sysqioreq so that the insert-irp entry gets called for drivers via the driver pending-io entry (which can be trapped). You have to be able to rebuild IO_ROUTINES.EXE to use this, but the mod is tiny. Unfortunately all this got done before I got here, or I'd have warned folks about it. DKdriver sets its UCB busy a fair amount during error conditions, when internal SCSI device queues signal busy, during io datacheck ops, at mount verify or cluster state transition, and some more, so you can't count on it not being set. In all of the sys facility, only sysqioreq, mbdriver, and nldriver refer to EXE_STD$INSERT_IRP and that's just due to the DDTAB macro for the drivers, so it is conceivable to just steal the entry of insert-irp and pray that nothing else calls it, and look at the UCB and thus get a look at IRPs on their way in. For the moment that's the only game in town. My hack may make it into sysqioreq for the next rev, and maybe into a 1H release, but it'll miss 7.1...that is too close to release and I didn't find out about the full magnitude of the screwup (well, I consider it one) till too late to wedge a mod to sysqioreq into 7.1. Too much testing's called for. What I'd really LIKE to see is a series of mods to the i/o exec that will have a stack space in each IRP for intermediate status etc. type stuff, and another ddtab entry for the looping issues that may have to be handled from macro-64 but which would be used as a place which every IRP would have to pass by FROM INSIDE STARTIO, and which would not shove more junk on a stack, just call an address more or less bare and thus continue, no stack mods at all. It would need to be basically a jump target, but that needs to be somehow compilable on Alpha (in C for political etc. reasons) and would need to be useful somehow. That may turn out to be a tall order. If you have comments or even code suggestions, as a 3rd party ISV (who's still third party...my word on this is likely to be disvalued internally since my outside stuff...even what isn't on the market yet...gets viewed as not "really" outside) they may be quite helpful in getting some such mods made. I'd like to arrange that any Alpha drivers that play these games again have some method for just looking in ONE place for packets again. Having to look in several is a nuisance, to put it in the politest terms available. (Tis pity btw that your colleagues at Symark never got very far with my security stuff. Happened to be talking to a mainframer at a large insurance co. last week (who is dis-satisfied with IBM's next gen performance and seemed interested in that of VMS with VLM) and when I described my Safety package to him, he noted that --all unknown to me--apparently the major IBM mainframe security addons (stuff with names like RACF and Top Secret) do the same general operations. While I was disappointed to hear that someone had done some of the security stuff I had come up with out of my head, it was interesting to think that there's apparently at least one very large market with considerable money floating around needing exactly what I have. Symark and I corresponded a while but nothing ever came of it...while meanwhile I keep improving the pkg and adding stuff.) Back to topic. I'm working up a design spec for my multipath switching code (which can manage if at least the pending IO entry is stealable), I will be pushing for the IRP stack, the extra DDTAB entry, and a couple other interecept speedups I have running here in a section of that document. Provided that passes muster, a retrofit of at least sysqioreq should be simple enough. I may be able to even get that slipped out on the side as a copy of io_routines.exe for those who need it. Does this address your issues? Glenn C. Everhart Everhart@star.enet.dec.com (work) Everhart@Arisia.GCE.Com (home) 603 881 1497 office 603 465 9517 h 603 465 9518 fax (also everhart@gce.com works, or everhart@gce.mv.com) ================== RFC 822 Headers ================== Return-Path: everhart@row.enet.dec.com Received: by spia.rdperf.com (UCX V4.1-12, OpenVMS V6.1 Alpha); Mon, 23 Dec 1996 09:21:03 -0800 Received: from us2rmc.zko.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA01319; Mon, 23 Dec 1996 12:06:24 -0500 (EST) From: Received: from row.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA20569; Mon, 23 Dec 96 11:42:23 -0500 Message-Id: <9612231642.AA20569@us2rmc.zko.dec.com> Received: from row.enet; by us2rmc.enet; Mon, 23 Dec 96 12:04:54 EST Date: Mon, 23 Dec 96 12:04:54 EST To: "rick@rdperf.com"@3049.ENET.dec.com Cc: everhart@row.ENET.dec.com Apparently-To: rick@rdperf.com Subject: RE: DKDRIVER & Device I/O Intercept % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA04585; Mon, 23 Dec 96 15:13:56 -0500 % From: rick@rdperf.com % Received: from SPIA by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA21728; Mon, 23 Dec 1996 15:01:41 -0500 (EST) % Date: Mon, 23 Dec 1996 11:16:17 -0800 % Message-Id: <96122311161750@rdperf.com> % To: row::everhart, marty@symark.com % Subject: Re: DKDRIVER & Device I/O Intercept % X-Vms-To: SMTP%"everhart@row.enet.dec.com" % X-Vms-Cc: MARTYK,RICK