bug-hurd
[Top][All Lists]
Advanced

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

Re: RFC: [PATCH] SCM_CREDS support


From: Samuel Thibault
Subject: Re: RFC: [PATCH] SCM_CREDS support
Date: Sun, 20 Sep 2015 13:17:36 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Samuel Thibault, le Thu 05 Mar 2015 03:23:46 +0100, a écrit :
> Samuel Thibault, le Thu 05 Mar 2015 03:07:18 +0100, a écrit :
> > Was the synchronous/asynchronous issue solved?
> 
> I guess not, and I think I know why: in the
> auth_server/user_authenticate loop, the server passes a port back to the
> user.  This is thus a complete rendez-vous: auth_user_authenticate won't
> return before auth_server_authenticate is called, and vice-versa.  From
> the point of view of send/recv, send should be non-blocking, so it's a
> problem.  I'm however thinking that we could probably add a variant of
> the auth_user_authenticate RPC which does not wait for the server part,
> by dropping the newport parameter.

Actually, no need for non-blocking a variant, we can just make the
client send the RPC request and not wait for the reply.  The idea is to
generate the __auth_user_authenticate_request stub in libhurduser by
doing this:

--- hurd/Makefile.orig  2015-09-20 11:15:27.000000000 +0000
+++ hurd/Makefile       2015-09-20 11:15:28.000000000 +0000
@@ -29,7 +29,7 @@
 # The RPC interfaces go in a separate library.
 interface-library := libhurduser
 user-interfaces                := $(addprefix hurd/,\
-                                      auth startup \
+                                      auth auth_request auth_reply startup \
                                       process process_request \
                                       msg msg_reply msg_request \
                                       exec exec_experimental exec_startup 
crash interrupt \

and then in the send side one can do:

        mach_port_t reply = __mach_reply_port();
        err = __USEPORT(AUTH, __auth_user_authenticate_request (port, reply, 
MACH_MSG_TYPE_MAKE_SEND, rendezvous, MACH_MSG_TYPE_MAKE_SEND));
        mach_port_deallocate(__mach_task_self(), reply);

The receiving side may still send a newport to the reply port, but
that'll get nicely dropped by GNU Mach.

I'll have a stab at cleaning your patches.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]