DragonFly BSD
DragonFly kernel List (threaded) for 2004-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Caps status

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 20:32:48 -0800 (PST)

:I see that there are some caps tests now in the CVS...
:That seems to imply to me that the API is solidified somewhat?
:Just curious what it's status is because I'd like to see if I can write
:up a little useful demo or something with this API and get it on the docs

    The system call API has solidified pretty well, but there's only a
    synchronous implementation at the moment (which is just fine if
    you want to start playing around).

    I need to write up some documentation.  Basically the way it works
    is that the server registers a rendezvous point (name,uid,gid)
    and the client connects to it (name,uid,gid).

    The client sends the server a message.  The client's message is
    opaque data and will not be copied from the client's address space
    to the server until the server reads the message.

    The server reads the message (the state will be CAPMS_REQUEST in the
    caps_msgid that the syscall fills in), processes it, and sends a 
    reply.  The server may send arbitrary opaque data in the reply.  The
    data will not be copied until the client reads the reply.

    When the client reads the reply (the state in the message id returned
    by the system call will be CAPMS_REPLY), the message is returned to the
    server yet again in state CAPMS_DISPOSE, which tells the server that
    it can dispose of the data it sent in the reply.

    That's the basics in a nutshell.  Eventually we will support an
    asych notification interface through the 'upcid' argument
    in caps_sys_client() and caps_sys_server(), but it's ignored for
    the moment (and we will eventually support both kqueue notification
    and upcall notification).

    The connection is many-to-1.  The server need register the service
    just once to receive and reply to messages from multiple clients.
    The server is given no indication (yet) of when a client connects
    or disconnects from the service.

    The various routines can also return a caps_cred associated with
    the message.  I haven't tested this part yet but it should work.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]