From: SMTP%"everhart@star.zko.dec.com" 24-DEC-1996 17:52:37.38 To: EVERHART CC: Subj: sugg. on io Date: Tue, 24 Dec 1996 14:31:31 -0500 Message-Id: <96122414313111@star.zko.dec.com> From: everhart@star.zko.dec.com (Glenn C. Everhart 603 881 1497) To: everhart@gce.com Subject: sugg. on io X-VMS-To: SMTP%"everhart@gce.com" From: 3049::"rick@rdperf.com" 24-DEC-1996 14:10:16.56 To: row::everhart CC: Subj: Re: DKDRIVER & Device I/O Intercept Glenn, I will test those drivers to see if they work on our cluster. I can try the 7.0 version and will also try the 6.2 version. I thought of a possible solution that would not require a change at all I wanted to run by you. By the way, how would you easily identify that the driver for this UCB was DKDRIVER? We have an inhouse kluge, but I thought you might know of a better way. The basic approach would be to duplicate the UCB when we setup the intercept. We would then get the IRP via the original UCB (pointed to by the DDB). We would then modify IRP$L_UCB to point to the duplicate and pass it along to the real device driver. We would need to reinit UCB$L_IOQFL and I suspect we would need to mirror the REFC, DEVDEPEND* & DEVCHAR* fields in order to keep all of that okay. Besides those problems, I can't think of any other problems with this approach. It wouldn't work for DUDRIVER because of alternate UCB issues, but it should work for DKDRIVER. Sincerely, Rick Cadruvi everhart@row.enet.dec.com wrote: > > I was thinking some more about your idea. It might work ok after all, > (that is forking before looping back, and calling the startio entry). > Means an extra PALcode call or three and interrupt for each of those > operations, but since they all start kernel processes anyhow, maybe > it wouldn't matter all that much. I could cobble up a fix pretty > fast for 6.2 or 7.0; I have some dkdriver sources I've been partly > updating as fixes are found and adding a fork to each would not be > that hard, if you want to try them out that way. I had gotten a warning > verbally that something of the kind had been tried and failed under > load 'way back, but it may not have been exactly what you proposed, and > the guy who told me is no longer here. There was (I hear) a lot of schedule > pressure then. > > BTW, another of my little hacks will allow one to avoid the detour > thru IPL4 on posting. You need to be a tad careful with it, but I'm > using it. Wanted to get it in fully before this, but without a streams > type designt to tie it to officially, it got viewed as an "interesting, > nice to have" thing, i.e., low priority. I can kick it higher now. > > The pending io scheme would let you see all IRPs that will get to start-io; > I need to test it a bit more, and also be sure it doesn't mess up the > fast-io work with dudriver. I can't see how it could give trouble, but > dudriver is pretty complex and there may be something subtle... > > What version of VMS do you have to fiddle with just now? I could try to > cobble up the dkdriver mods that use a fork...might be a faster way to > get something into your hands...and just build the suckers today for > 6.2/7.1. You'd pick up a little extra stuff...the drivers are more tolerant > of 3rd party SCSI disks than the standard issue ones, since they've got > some of my 7.1 mods wedged in, and the 6.2 driver has some old test code > that might even read 2048 byte CDs buried in there. > > My cautions about prior experience trying to fork and re-call the startio > entry are (as I think about it) too vague not to try this with. The > performance implications (folks are very sensitive about those here) > are another matter. I suspect that getting pending ios via the driver > will fly better, especially since dptab already has by default a pointer > to the insert_irp routine, so I can just call insert_irp via the > ddtab entry (oops...meant ddtab above, not dptab). DUdriver looks like > it'd be ok at least to first order, though. Best I can suggest is that if > you care to try a dkdriver with a fork, and it seems ok under load, the > scheme may allow 6.2/7.0 and maybe even 7.1 customers to get something > that'll work quickly while the politics of altering the exec are > dealt with. > > Personally I believe the ability to do this kind of intercept is important to > preserve,and am appalled that it was messed up with total unconcern > in this way. (And the special case code that VIOC has to use to do > its work IMO seriously lacks elegance...again being polite.) So > you're preaching to the choir to a certain extent here. > > I have the 6.2 driver mod coded now...let me see if it builds. You > wanna test? Also can you decode mftu encoded zip? (unzip and mftu > can be found on sigtapes, at ftp.wku.edu (in [.vms.fileserv]), on > freeware v3, etc...) > glenn > ================== RFC 822 Headers ================== > Return-Path: everhart@row.enet.dec.com > Received: by spia.rdperf.com (UCX V4.1-12, OpenVMS V6.1 Alpha); > Tue, 24 Dec 1996 06:43:20 -0800 > Received: from us2rmc.zko.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) > id JAA20616; Tue, 24 Dec 1996 09:35:47 -0500 (EST) > From: > Received: from row.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) > id AA09033; Tue, 24 Dec 96 08:49:48 -0500 > Message-Id: <9612241349.AA09033@us2rmc.zko.dec.com> > Received: from row.enet; by us2rmc.enet; Tue, 24 Dec 96Received: from row.enet; by us2rmc.enet; Tue, 24 Dec 96 09:35:30 EST > Date: Tue, 24 Dec 96 09:35:30 EST > To: "rick@rdperf.com"@3049.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 AA27024; Tue, 24 Dec 96 14:04:33 -0500 % Received: from acme.sb.west.net by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA32598; Tue, 24 Dec 1996 13:50:45 -0500 (EST) % Received: from pc2 ([205.254.244.196]) by acme.sb.west.net (8.8.3/8.6.12) with SMTP id KAA26128 for ; Tue, 24 Dec 1996 10:40:35 -0800 (PST) % Message-Id: <32C02595.598B@rdperf.com> % Date: Tue, 24 Dec 1996 10:48:53 -0800 % From: Rick Cadruvi % Reply-To: rick@rdperf.com % Organization: R&D Performance Group % X-Mailer: Mozilla 3.0Gold (Win95; U) % Mime-Version: 1.0 % To: row::everhart % Subject: Re: DKDRIVER & Device I/O Intercept % References: % Content-Type: text/plain; charset=us-ascii % Content-Transfer-Encoding: 7bit