At Mon, 17 Feb 2014 23:35:12 +0100,
Richard Braun wrote:
>
> On Mon, Feb 17, 2014 at 06:20:54PM +0100, Justus Winter wrote:
> > +@deftypefun kern_return_t mach_port_set_protected_payload (@w{ipc_space_t
> > @var{task}}, @w{mach_port_t @var{name}}, @w{unsigned long @var{payload}})
> > +The function @code{mach_port_set_protected_payload} sets the protected
> > +payload to @var{payload}. If @var{payload} is non-zero, the
> > +@code{msgh_protected_payload} field will be set to @var{payload} if a
> > +message is delivered to @var{name}.
>
> If I'm right, this also means switching back from the protected payload
> is done by calling this RPC with a payload of 0. It could be worth
> emphasizing that 0 is an invalid value for a protected payload.
These semantics are unfortunate. 0 should be valid. Add another IPC
to clear the pp or add a parameter to this IPC called, say, set, which
if true sets the pp to the provided value and otherwise clears the pp.
Neal
