Re: proc_task2proc prototype change

[Justus Winter]

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

> Hello,
>
> Justus Winter, on mar. 09 mai 2017 10:25:31 +0200, wrote:
>> 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.
>
> Well, at least we need some solution for now, otherwise we get stuck :)
>
> AIUI, the least-ugly solution is to define a new type, which in the
> server is defined to mach_port_poly_t and in the client is defined to
> mach_port_t?

As usual, the gods were way ahead of us, and introduced a way to specify
a different type for the client and server side, and there is even
already exactly the type that we need.  Quoting from the fine "Mach 3
Server Writers Guide":

> The other major use of transmission type changes is to specify a
> parameter (most likely a port type) that is polymorphic on the
> sender’s side (user side for in parameters, server side for out
> parameters, both for inout parameters) but of a known type on the
> receiver’s side. That is, the sender will specify a port and a port
> type, but the result of sending this port will be to generate a known
> port type. The following built-in MIG types have such a specification:
>
> [1]    type MACH_MSG_TYPE_PORT_RECEIVE =   -1 | 16;
> [2]    type MACH_MSG_TYPE_PORT_SEND =      -1 | 17;
> [3]    type MACH_MSG_TYPE_PORT_SEND_ONCE = -1 | 18;

With the corresponding Mach type mach_port_send_t.  I committed a fix.

Justus

signature.asc
Description: PGP signature