troubles with caps

[Matthew Dillon]

:I've been playing with it quite heavily in the past few days and I like
:it a lot.  I have two questions about it though, if you don't mind:
:
:Do you have any plans to introduce a timeout to (say) caps_sys_wait, so
:that if a message doesn't come in in a certain time frame, it returns
:with errno == ETIMEOUT or similar?

    I've been thinking about tying it into the file descriptor subsystem
    but there are issues related to programs fork()ing and closing all
    descriptors that makes it difficult for a libc implementation to
    properly deal with the fork.

    But, yes, I think we do need some sort of timeout feature.

:And, when the process which is holding a connection dies, does that
:connection die too?  From the looks of the client example (which forks)
:I'm guessing no, the connection sticks around and can be shared by
:several processes.  But is there a guarantee of that?  Say I'd like to

    The connection is actually NOT shareable between processes that
    fork().  What happens when you fork is that a dummy placeholder
    connection is created in the child so if the child tries to access
    the CAPS descriptor it gets a specific error that it can check for and
    know when to reconnect.

    The problem with closing out the CAPS descriptor is that if the child
    process then makes various other CAPS connections before attempting 
    to use a connection it think is still good from before the fork, the
    new connections might reuse the ID that the original connection had.

:be able to receive a message with one process and pass the connection id
:to another process that replies to it.  In the meantime the first
:process might exit... should I instead be re-establishing a new
:connection in each process?
:
:-Chris

    You can't pass connection id's.  If we implement a file descriptor based
    approach then it would be possible to pass connection id's but the
    hanging point there are as described above... programs which close all
    available descriptors.

    I'm not sure how advantageous it would be to pass CAPS connections between
    processes, since a process can easily reconnect to the CAPS service and/or
    the original process can create a new service that the new process
    connects to.  I think it might be better to enforce the current API
    which allows no connection inheritance or passing.

    From a security standpoint we might want to manage capabilities through
    the CAPS system (in the future), and in that case we definitely do not
    want to allow connection inheritance.  At the moment that's just a
    pipe dream.  I have to add a way for the server to recognize a particular
    client's connection before capability management can be done properly.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>