From:	AITGW::"MACRO32@WKUVX1.BITNET" 22-FEB-1992 05:44:35.42
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Bug in IOC$SEARCHDEV??!!!??

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Sat, 22 Feb 92 05:42:17 EST
Received: from ukcc.uky.edu by aitgw.ge.com (5.65/GE Gateway 1.4)
	id AA10562; Sat, 22 Feb 92 05:42:04 -0500
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 9962; Sat, 22 Feb 92 05:37:17 EST
Received: from UKCC by ukcc.uky.edu (Mailer R2.08) with BSMTP id 3645; Sat, 22
 Feb 92 05:36:52 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 3559;
 Sat, 22 Feb 92 05:35:31 EST
Errors-To: MacroMan@WKUVX1.BITNET
X-Listname: "VMS Internals, MACRO, and BLISS Discussions"
    <MACRO32@WKUVX1.BITNET>
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.0A) with BSMTP; Sat, 22
          Feb 1992 04:36:33 EST
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 9105; Sat,
          22 Feb 92 05:28:48 EST
Received: from optima.cs.arizona.edu by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with
          TCP; Sat, 22 Feb 92 05:28:47 EST
Received: from VESTA.SUNQUEST.COM by optima.cs.arizona.edu (4.1/15) id AA26085;
          Sat, 22 Feb 92 03:28:55 MST
Date: Sat, 22 Feb 1992 3:28:37 -0700 (MST)
From: <GAVRON@vesta.sunquest.com>
Reply-To: MACRO32@WKUVX1.BITNET
Message-Id: <920222032838.6c@VESTA.SUNQUEST.COM>
Subject: Bug in IOC$SEARCHDEV??!!!??
To: MACRO32@WKUVX1.BITNET
X-Vmsmail-To: MACRO32@WKUVX1.BITNET
 
Date sent:  22-FEB-1992 03:23:23
 
 
        In a comp.os.vms discussion, jwilkinson@lucy.claremont.edu
        pointed out that in V5.5 pending reads on a mailbox did not
        show up in ucb$l_irp.
 
        I found that the V5.5 MBDRIVER now maintains separate queues
        and that ucb$l_mb_readqfl and writeqfl are the places to
        look.
 
        HOWEVER, in writing some test code, I discovered that
        IOC$SEARCHDEV uses the IFNORD macro to determine if it
        can access the device name descriptor; this means that
        the descriptor *must* be stored in a location accessible
        to the previous processor mode!  In other words, what I
        was trying to do (build a descriptor on the kernel stack
        and then send (sp) through) would not work, *unless* I
        jumped into kernel again... (sample code below sig)
 
        Should I SPR this or did I goof?
 
        Ehud
 
--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
savsp:  .blkl   1
dev:    .ascid "TTT"
chan:   .blkl   1
ucb:    .blkl   1
ucb2:   .blkl   1
        .library "sys$Library:lib.mlb"
        .link "sys$system:sys.stb"/selective_search
        $pcbdef
        $ucbdef
        $irpdef
        .entry  test,^m<>
        $cmkrnl_s       routin=getucb
        blbs    r0,20$
        ret
20$:
        $cmkrnl_s       routin=getucb2
        blbs    r0,30$
        ret
30$:
        $exit_s r0
 
        .entry  getucb,^m<>
        moval   dev,r1
        jsb     g^ioc$searchdev
        movl    r1,ucb
        ret
 
        .entry  getucb2,^m<r2,r3,r4,r5>
        movl    ucb,r5
        movl    ucb$l_mb_readqfl(r5),r3         ; get IRP
        movzwl  irp$l_pid(r3),r1                ; get IPID
        movl    @sch$gl_pcbvec[r1],r4           ; get PCB
        tstl    pcb$l_eowner(r4)                ; is it a subprocess?
        beql    10$                             ; nope, go on
        movl    pcb$l_eowner(r4),r0             ; get epid of owner process
        jsb     g^exe$epid_to_pcb               ; convert to pcb address
        tstl    r0                              ; see if we failed
        bneq    5$                              ; nope
        movl    #ss$_unsupported,r0             ; yup, we failed
        ret                                     ; so go out gracefully
5$:
        movl    r0,r4                           ; put owner pcb in r4
10$:
        movl    #1,r1                           ; increment pointer
        pushab  pcb$t_terminal(r4)[r1]          ; get terminal name string ptr
        movzbl  pcb$t_terminal(r4),-(sp)        ; get length of terminal name
;
; You'd think I could just do:
;       movl    sp,r1
;       jsb     g^ioc$searchdev
;
; Unfortunately IOC$SEARCHDEV uses IFNORD.  Since this descriptor is
; being built on the kernel stack, guess what, it's not readable from
; the previous (user) mode.  Hence IOC$SEARCHDEV returns SS$_ACCVIO
; even though one can even:
;       pushl   sp
;       calls   #1,lib$put_output
; and get it out...
; Instead we must restort to:
;
        movl    sp,savsp
        $cmkrnl_s       routin=getucb3
;
; I think it's a bug... comments?
;
        movl    (sp)+,(sp)+                     ; reset stack pointer
        ret
;
; This stuff ought not to be necessary...
;
        .entry getucb3,^m<r2,r3>
        movl    savsp,r1                        ; put descriptor address in r1
        jsb     g^ioc$searchdev                 ; get ucb for terminal
        movl    r1,ucb2
        ret
        .end    test
