From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 10-MAR-1994 14:24:16.37
To:	EVERHART
CC:	
Subj:	Re: microkernel alleged benefits

X-Newsgroups: comp.os.vms
From: danh@qnx.com (Dan Hildebrand)
Subject: Re: microkernel alleged benefits
Message-ID: <-c749fk@qnx.com>
Date: Wed, 09 Mar 94 19:56:03 GMT
Organization: QNX Software Systems
Lines: 76
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET

In article <940307153542.94@arisia.gce.com>,  <EVERHART@arisia.gce.com> wrote:
>It can be rather useful to be able to arrange for a program to gain
>control of open/close/read/etc. as has been said the Hurd is moving
>toward. However, in my talks at the last two DECUS symposia I have
>given the methods by which one does this in VMS. A well defined interface
>to these calls is required; a microkernel appears not to be a requirement,
>though it might provide some simplification. Not that the VMS flavor is
>all that complicated...most of the complexity has to do with pushing
>performance up. My session notes were fairly complete and the F93 flavor
>will appear on the fall '93 sigtapes, due out momentarily.
>Glenn Everhart
>Everhart@Arisia.GCE.Com

Here's some pseudo-code showing how it would be done in a QNX microkernel 
environment.  This source code would be compiled like any user program and 
when run with sufficient priviledge, would appear in the pathname space as 
/proc (the portion of the pathname space it chose to adopt).  It can be 
started and stopped like any user process, and source-level debugged.  When 
another process does I/O to the /proc namespace, the system shared libs 
will convert the various POSIX I/O calls (open, close, read, write, 
readdir, etc) into messages which are sent (via the microkernel) to this 
process.  All the resource managers in QNX are implemented in this manner 
(the '/' file system, /dev, etc), meaning that "guest" file systems are as 
"native" as any other file system present.  This approach preserves all the 
POSIX semantics and passes the NIST POSIX test suite.

This process can also contain interrupt handlers, which the kernel will
hook to hardware interrupt vectors, allowing interrupt processing to also 
be done within the code/data context of the process (but running at 
interrupt time).  If a significant event happens, the interrupt handler can 
cause the process to awaken from the receive() call and resume execution 
with the data placed into it's space by the interrupt handler.

#include <various header files>

union {        // A union of various messages that might arrive in the buffer
    msg_t                   type;
    msg_t                   status;
    struct _io_open         open;
    struct _io_write        write;
    struct _io_read         read;
//    etc...
} msg;

main(int argc, char *argv[]) {

//  Attach the resource manager into the pathname space
    if ( qnx_prefix_attach( "/proc", NULL, 0) == -1 ) exit( 1 );

//  Main event loop
    for(;;) {
        pid = Receive( 0, &msg, sizeof(msg) );  // Receive the message
        switch( msg.type ) {                    // Main switch loop
        case _IO_FSTAT:
            // Fill each switch entry with the appropriate code
            break;
        case _IO_OPEN:
            break;
        case _IO_CLOSE:
            break;
        case _IO_WRITE:
            break;
        case _IO_READ:
            break;
        case _IO_READDIR:
            break;
		// etc, etc.
        }
        Reply(pid, &msg, nbytes);   // Reply to client message
    }
}
-- 
Dan Hildebrand                     email: danh@qnx.com
QNX Software Systems, Ltd.         QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8

