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. Justus
signature.asc
Description: PGP signature
