bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH 5/5] ipc: provide the protected payload in ipc_kmsg_copyout_h


From: Justus Winter
Subject: Re: [PATCH 5/5] ipc: provide the protected payload in ipc_kmsg_copyout_header
Date: Thu, 18 Sep 2014 15:22:10 +0200
User-agent: alot/0.3.5

Quoting Samuel Thibault (2014-02-22 15:29:32)
> Justus Winter, le Fri 21 Feb 2014 17:49:28 +0100, a écrit :
> > * ipc/ipc_kmsg.c (ipc_kmsg_copyout_header): If a protected payload is
> >   set for the destination port, provide it in msgh_protected_payload.
> > * doc/mach.texi (Message Receive): Document message semantics with
> > protected payloads.
> 
> Mmm, isn't this missing the fast copyout in mach_msg.c around
> lines 1139, 1177, 1212?

Yes, I have amended the patch to include these.

> I'm also wondering about the special versions
> ipc_kmsg_copyout_pseudo() and ipc_kmsg_copyout_dest(),

Both of these cast kmsg->ikm_header.msgh_remote_port to ipc_object_t,
which aiui could also be a port set.  But the destination port cannot
be a port set, so maybe the code is just overly generic for some
reason.  I guess we could set the protected payload in
ipc_kmsg_copyout_dest.  I'm not too sure if it makes sense for
ipc_kmsg_copyout_pseudo, I'm a little fuzzy on the semantic of that
one.

> and exception_raise().

I guess we could implement the protected payload here in the fast path
version of ipc_kmsg_copyout_dest as well as in the slow path.  Then
again, these exception messages are sent to a tasks message port,
right?  If so, then the server code in the glibc will have to be
adapted to take advantage of protected payloads anyways.  This is not
a priority for me.

All the userspace code I have written operates under the assumption
that the protected payloads are an optimization.  This makes it
possible to use the binaries on older kernels and provides an easy and
robust upgrade path.

Justus



reply via email to

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