From:	SMTP%"dipirro@star.enet.dec.com"  6-JAN-1995 15:59:11.78
To:	EVERHART
CC:	
Subj:	Re: AXP, Locking Pages for Kernel Mode

From: dipirro@star.enet.dec.com (Steve DiPirro)
X-Newsgroups: comp.os.vms
Subject: Re: AXP, Locking Pages for Kernel Mode
Date: 6 JAN 95 15:23:44 EST
Organization: Digital Equipment Corporation
Lines: 93
Message-ID: <3ek9on$7jq@jac.zko.dec.com>
NNTP-Posting-Host: STAR
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET


In article <01HLGI51LI9Y8WZXZF@splava.cc.plattsburgh.edu>, "Thomas M. Deso" <DESOTM@splava.cc.plattsburgh.edu> writes...

>	Steve, this was not the case in this specific inquiry but as I do 
>	have some more porting from Macro-32 to DECC to do I would be very 
>	interested in the descriptions to this interface.  I did a search
>	of the DECC header (.H) and (.TLB) but did not find any references
>	to these routines, on OpenVMS/AXP Version 6.1.

Well, I did a search and didn't find function prototypes defined for these
routines. That's an oversight. They should be in EXE_ROUTINES.H in
SYS$LIBRARY:SYS$LIB_C.TLB, and we'll need to add them. In the meantime, if
you have the interface descriptions, you can always hack up your own prototypes
until we provide them.

The routines are both standard calls, available on AXP by linking against
SYS$BASE_IMAGE (i.e. linking /SYSEXE). The routines happen to be written
in BLISS and look strangely familiar to me as I look at them. Hmmmm. Here
are the routine headers with interface descriptions:

GLOBAL ROUTINE exe$read_process(
!++
! Functional description:
!
!       This routine is responsible for fetching data from the address
! space of another process and copying it into the specified local buffer.
! An ACB is allocated to contain the vital information for this data
! transfer and then an AST is delivered to the target process to actually
! snatch the data. The data is read into nonpaged pool in the context of
! the target process. The AST is then fired back at this originating process
! to complete the read operation, where the data is copied from pool into
! the local address.
!       Sounds simple enough...So what are we waiting for...
!
! Formal parameters:
!
        ipid,                           !Target process internal PID
        buffer_size,                    !Number of bytes to transfer
        target_address,                 !Address in target process
        local_address,                  !Address for data in local process
        target_address_type,            !Either virtual memory or register
        ast_counter_address             !Address of a counter to identify
                                        ! the different reads/writes
        ) =

GLOBAL ROUTINE exe$write_process(
!++
! Functional description:
!
!       This routine is responsible for writing data from the address
! space of the calling process to the address space of another process.
! An ACB is allocated to contain the vital information for this data
! transfer and then an AST is delivered to the target process to actually
! write the data. The data is stored in nonpaged pool until running in the
! context of the target process, where it is copied into the target address.
! The AST is then fired back at this originating process to complete the
! write operation.
!
! Formal parameters:
!
        ipid,                           !Target process internal PID
        buffer_size,                    !Number of bytes to transfer
        local_address,                  !Address of data in local process
        target_address,                 !Address in target process
        target_address_type,            !Either virtual address or register
        ast_counter_address             !Address of a counter to identify
                                        ! the different reads/writes
        ) =

>	This is exactly what I want to do, but I was under the impression 
>	that I had to lock ANY code or data referenced in Kernel mode 
>	regardless of the IPL!  After looking at several examples of C code
>	available from the net, I have found cases that range from NO 
>	locking in kernel mode to locking everything!  Confusing...

Basically, you want to avoid TNV traps and subsequent pagefaults when above
IPL 2. So the code pages and their corresponding linkage section pages must
be locked in memory and resident. Any data which is touched by the code must
also be locked and resident. When at IPL 2 or below, you don't have to worry
about it.

>	While these #pragmas were not documented in the bookreader doc's I
>	received with our AXP2100 or the help files for the DECC, I tried
>	them and they appear to work as	you say.  I am very grateful for 
>	this information Steve and I thank you.

You're welcome, and I'll try to find out why these didn't make it into
the documentation. They were fairly late additions to the compiler for V6.1.

------------
Steve DiPirro        dipirro@star.enet.dec.com

------------