Hi, On Wed, Aug 26, 2009 at 04:21:43PM +0200, Carl Fredrik Hammar wrote:
> + * The client sends an `ioctl_handler_request' to the server, > + with a rendezvous port. > + > + * The server sends an `ioctl_handler_acknowledge' in reply, this > + is needed so that the client won't wait indefinitely for > + `auth_server_authenticate' to return if the server does not support > + this protocol. > + > + * The client sends an `auth_server_authenticate' with the rendezvous > + port and a reply port to the auth server. (Note the reversal of > + the roles of client and server from the normal auth protocol.) > + > + * The server sends an `auth_user_authenticate' with the rendezvous > + port to the auth server. > + > + * The auth server matches up the requests using the rendezvous port, > + and returns the reply port to the server and the server's ID block > + to the client. > + > + * The server sends a port to a file that can be opened with `dlopen' > + and exports an`ioctl_handler_t' typed function named > + `hurd_ioctl_handler'. This last bit is the ioctl_handler_reply part I think? I think the protocol could be simpified a lot by using a normal RPC, and letting the server wait for the auth_user_authenticate() reply asynchronously. (Or not wait for it at all, if auth can deal with this...) The server is not really interested in the result of the authentication -- there is no reason to wait for it before returning the module file... Also, the detailed description of the protocol should probably go into the Hurd reference manual... -antrik-
