Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!LBL.ARPA!nagy%warner.hepnet
From: nagy%warner.hepnet@LBL.ARPA (Frank J. Nagy/VAX Guru)
Newsgroups: comp.os.vms
Subject: (none)
Message-ID: <871007055436.043@Lbl.Arpa>
Date: Wed, 7-Oct-87 08:54:35 EDT
Article-I.D.: Lbl.871007055436.043
Posted: Wed Oct  7 08:54:35 1987
Date-Received: Sat, 10-Oct-87 09:41:21 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 63

>> 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