pstevens@pioneer.arpa (Paul Stevens RCE Sterling) (10/06/87)
This is a question regarding using the user supplied system service mechanism. A user here set up his own system service using the dispatcher template found in SYS$EXAMPLES. He was then trying to make a QIO call from within the system service routine (executing in kernel mode) in which it would use the Connect-to-Interrupt driver for controlling a KW11 clock (convoluted huh?). The purpose of all of this was to let users who create many different executable images using the CONINTTER code to use it without having to grant them all CMKRNL priv. (note that the CONINTER code has a start-IO routine which implies CMKRNL needed) and without having to install each new image with priv's. The idea was that once in kernel mode the CMKRNL priv would be given (temporarily) since kernel code has SETPRV by default and then the QIO would be issued. However, a crash would result apparantly in ASTDEL after the QIO. The question is...Is it possible to issue a QIO after having been dispatched through a CHMK inst to the user routine (using the negative code value). I'm sure that the dispatching was occurring correctly. I seem to vaguely remember that it is not possible to call QIO from within kernel mode. Anybody remember for sure? and if not what is the problem? As this is rather limited in general interest you might want to email. Thanks Paul Stevens NASA Ames Research Center Moffett Field CA 94035 (415)694-4887
adelman@LBL-CSA2.ARPA (Kenneth Adelman) (10/07/87)
> The idea was that once in kernel mode the CMKRNL priv would be given > (temporarily) since kernel code has SETPRV by default and then the QIO > would be issued. However, a crash would result apparantly in ASTDEL > after the QIO. > The question is...Is it possible to issue a QIO after having been > dispatched through a CHMK inst to the user routine (using the negative > code value). I'm sure that the dispatching was occurring correctly. > I seem to vaguely remember that it is not possible to call QIO from within > kernel mode. Anybody remember for sure? and if not what is the problem? There are all sorts of bad implications for having a kernel mode system service which in turn calls SYS$QIO with the users arguments. For one, SYS$QIO will be probing its arguments against access in KERNEL mode, not against access in USER mode, because SYS$QIO goes through the CHMK dispatcher a second time. The easier way to do it is to call the EXE$QIO entry point that the VMS CHMK dispatcher calls in kernel mode after YOU call SYS$QIO. Below is an example of how to write a user written system service which is a deprivileged $GETJPI call. This is expected to be called via the dispatcher in SYS$EXAMPLES. The argument count must be verified and the argument list probed. .ENTRY CIT_GETJPI,^M<R4,R11> ; ; This is the deprivileged $GETJPI. ; MOVL W^PCB$Q_PRIV(R4),R11 ;Save our privileges. BBSS S^#PRV$V_WORLD,W^PCB$Q_PRIV(R4),10$ ; TURN ON WORLD 10$: CALLG (AP),@#EXE$GETJPI ; CALL INTO $GETJPI (NOTE R4=CURPCB) MOVL R11,W^PCB$Q_PRIV(R4) ; RESTORE OLD PRIVILEGES RET Your code will probably look something like this, but will need additional checks that the caller is doing the particular $QIO to the particular device that you intend him to. Kenneth Adelman LBL
nagy%warner.hepnet@LBL.ARPA (Frank J. Nagy/VAX Guru) (10/07/87)
>> This is a question regarding using the user supplied system service >> mechanism. A user here set up his own system service using the dispatcher >> template found in SYS$EXAMPLES. My credentials: I write *lots* of user-written system services (I also crash *lots* of VAXes :-). >> He was then trying to make a QIO call >> from within the system service routine (executing in kernel mode) in >> which it would use the Connect-to-Interrupt driver for controlling a >> KW11 clock (convoluted huh?). The purpose of all of this was to let >> users who create many different executable images using the CONINTTER >> code to use it without having to grant them all CMKRNL priv. (note that >> the CONINTER code has a start-IO routine which implies CMKRNL needed) >> and without having to install each new image with priv's. >> The idea was that once in kernel mode the CMKRNL priv would be given >> (temporarily) since kernel code has SETPRV by default and then the QIO >> would be issued. However, a crash would result apparantly in ASTDEL >> after the QIO. >> The question is...Is it possible to issue a QIO after having been >> dispatched through a CHMK inst to the user routine (using the negative >> code value). I'm sure that the dispatching was occurring correctly. >> I seem to vaguely remember that it is not possible to call QIO from within >> kernel mode. Anybody remember for sure? and if not what is the problem? I have done the exact same thing, write a user-written system service to enable CMKRNL privilege to do a $QIO to the CONINTERR driver. Worked just fine. In my case, I was setting up an AMD-9519A Universal Interrupt Controller chip and handling attention interrupts from it (from a microprocess-based sort-of I/O channel). I have since eliminated the CONINTERR usage by taking the CONINTERR source (typed in manually :-( and verified by using one of the new VAX Disassemblers to disassemble CONINTERR.EXE and check against my code - only a half dozen errors :-). Starting from this, I stripped out much of CONINTERR and created my UICDRIVER (Universal Interrupt Controller driver). The Start and Cancel I/O routines I needed the CMKRNL privilege with for CONINTERR are now embedded in the driver. Sorry, off the track, back to the point. My code was even written in VAX C and did a $SETPRV to enable CMKRNL, the $QIO and then disabled the CMKRNL with another $SETPRV (unless CMKRNL was already enabled). The C routine was called by an outer shell written in MACRO which was the entry point from the CHMK instruction. The reason for the MACRO routine is that register R4 has to be saved since the change mode dispatcher sets up the current PCB pointer in R4. The MACRO shell was quicker to write than a program to read the .OBJ file from the VAX C compiler and modify the register save masks of the entry points to add R4 (maybe someday :-). In general, most system services can be called from kernel mode. Exceptions are the RMS services and any system services which use RMS (such as $PUTMSG, $GETUAI, $GETUAI, various other of the new security services). I have called services like $SETPRV, $QIO, $ENQ, $DEQ and $CRMPSC quite successfully from kernel mode. = Frank J. Nagy "VAX Guru" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510