Syscall messaging stage 2 commit

[Matthew Dillon]

    I've committed another incremental step for syscall messaging.  The
    commit implements the int 0x81 syscall entry point and is capable of
    taking system call 'messages' (constructed from sys/sysunion.h).

    At the moment the kernel just runs the system call synchronously, of
    course.  I am now investigating various system calls to figure out which
    ones can be most easily asynchronized.

    Below is some sample code (primarily for Peter and those people who are
    interested in the libcr threaded C library work).

    I did some preliminary performance tests just to make sure I wasn't 
    blowing it big time.  On a duel-P3/1.2GHz (Dell 2550) the direct syscall
    path was 909ns and the message-based path was 1077ns, which is close
    enough that I feel satisfied that the messaging interface will ultimately
    perform at least as well as the direct interface, especially once the
    syscall path is streamlined.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


#include <sys/types.h>
#include <sys/param.h>
#include <sys/msgport.h>
#include <sys/syscall.h>
#include <sys/sysproto.h>
#include <sys/sysunion.h>

static __inline
int
sendsys(void *port, void *msg, int msgsize)
{
    int error;
  
    __asm __volatile("int $0x81" : "=a"(error) : "a"(port), "c"(msg), "d"(msgsize) : "memory");
    return(error);
}

int
getuid_msg(void)
{
    static union sysunion sysmsg;
    int error;

    /*
     * In real life use a properly pre-initialized message, e.g. stowed in 
     * the thread structure or cached in a linked list somewhere.
     * bzero(&sysmsg.lmsg, sizeof(sysmsg.lmsg))
     */
    sysmsg.lmsg.ms_cmd = SYS_getuid;
    error = sendsys(NULL, &sysmsg, sizeof(sysmsg.getuid));
    ... this is where EASYNC would be handled ...
    return(sysmsg.lmsg.u.ms_result32);
}