Re: proc_task2proc prototype change

[Justus Winter]

Samuel Thibault <samuel.thibault@gnu.org> writes:

> Justus Winter, on dim. 07 mai 2017 17:42:24 +0200, wrote:
>> Can you paste the client code?
>
> kern_return_t __proc_task2proc
> (
>         process_t process,
>         mach_port_t task,
>         mach_port_t *proc,
>         mach_msg_type_name_t *procPoly

Interesting.  For a moment I thought that I missed that polymorphic can
also mean "not only a right, but maybe an integer", but I indeed used
the MIG type 'mach_port_poly_t', so it knows that it will be a right.  I
obviously wasn't aware that the client code will also get another
parameter.

This is really unfortunate, not only because I broke the libc build this
time (sorry), but because every use of the MIG type 'mach_port_t' aka
MACH_MSG_TYPE_COPY_SEND as an 'out' parameter severely limits what the
server code can do: It is not possible to move a send right when
returning from the rpc, making it impossible to interpose this rpc.  And
function interposing is at the heart of the Mach design.  Likewise for
'mach_port_make_send_t' and any other non-polymorphic right type.

To answer your previous question, how to do that only for the server
side: It is possible to do so using either some preprocessor trickery,
or some other means of transformation (awk) on the protocol
specification, or by manually rewriting and committing a specialized rpc
definition.  Every one of these techniques is used in the Hurd, and I
despise them all ;)

Maybe we can fix MIG so that we can get server-side-polymorphic right
parameters.  Because I see us doing what I've done for these three
procedures every time we want to interpose something, and interposing is
what Mach is about aiui.


Justus

signature.asc
Description: PGP signature