[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proc_task2proc prototype change
From: |
Justus Winter |
Subject: |
Re: proc_task2proc prototype change |
Date: |
Tue, 09 May 2017 10:25:31 +0200 |
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