new library, libcaps

[Matthew Dillon]

    Ok, I've committed a new library, libcaps.  This library is intended
    to encompass core userland threading features and IPC mechanisms.
    It currently contains an (incomplete) lwkt_thread.c, a more complete
    lwkt_msgport.c (both inherited from the kernel), an untested slab
    allocator ported from the kernel (it was easier to port then inherit),
    and my initial go at IPC functions which are the caps_*.c files.
    It is not intended to become a new libcr.  Instead it is intended to
    abstract mechanisms that libcr will wind up using.

    The new library is intentionally NOT hooked into buildworld.  It is also
    quite messy and incomplete at the moment, but works well enough to run
    the IPC test program I commited to /usr/src/test/caps.

    To run the IPC test program you need to create the appropriate directory
    infrastructure and make and install libcaps on a freshly installworld'd
    DragonFly system.

	mkdir /var/caps
	mkdir /var/caps/root
	cd /usr/src/lib/libcaps
	make; make install
	cd /usr/src/test/caps
	make

	as root:	/tmp/caps1 -s in one window and /tmp/caps1 -c in
			another window.

    This code is intended primarily for David Rhodus and Galen Sampson.
    David is going to be playing around with IPC and Galen has been working
    on userland threading. 

    Galen: there are a lot of pieces missing in the userland threading part
    of it.   e.g. it's missing the assembly switch functions, the globaldata
    is hacked, and curthread returns NULL :-).  It needs help!

    David: the library abstracts and demonstrates the IPC concept I've
    been talking about.  The only real concept problem is that at the moment
    the client cannot wait on its reply port for the message reply (because
    the threading support hasn't been added yet).  The test program uses
    a hacked library call to wait for message replies.  The library is 
    based on unix domain sockets and KQUEUE (and so can handle multiple
    connections and blockages without deadlocking the service).  It has not
    been well tested and there are almost certainly bugs, but the basics
    do work.  

    The IPC mechanism is fairly complex due to having to go through a non
    optimal unix domain socket.  Eventually the IPC mechanism will be moved
    into the kernel.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>