DragonFly kernel List (threaded) for 2004-01
Re: Caps status
: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.