Re: proc_task2proc prototype change

[Justus Winter]

David Michael <fedora.dm0@gmail.com> writes:

> On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter <justus@gnupg.org> wrote:
>> 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.
>
> Thanks, I can confirm that fixed bootstrapping compilers.  The reply
> functions still have mach_port_poly_t, though, and they are used by
> GDB.  Is that correct?

Oh wow, a server for the reply part of a protocol.  Odd.  Well, I
decided not to revert the change to the reply part so that it is
consistent with how the reply of a server for the full protocol works.

> It will require something like the following to get GDB to compile due
> to the changed generated definitions.
> [...]
>  ILL_RPC (S_proc_getmsgport_reply,
>       mach_port_t reply_port, kern_return_t return_code,
> -     mach_port_t msgports)
> +     mach_port_t msgports, mach_msg_type_name_t msgportsPoly)

Well, seeing that ILL_RPC is for unused procedures, it would be much
easier to use MIGs "new" way of creating default server stubs that
return a fixed value.  This can be done by #defining MIG_EOPNOTSUPP to
some value while compiling the MIG-generated server stub.  Being a
simpleroutine it doesn't really matter to what value, but EOPNOTSUPP
seems to be a better choice than ILL_RPC's 0.

Justus

signature.asc
Description: PGP signature