Samuel Thibault <samuel.thiba...@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