David Michael <fedora....@gmail.com> writes: > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter <jus...@gnupg.org> wrote: >> Samuel Thibault <samuel.thiba...@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
