Re: [PATCH] include: fix the definition of device_open

[Justus Winter]

Quoting Justus Winter (2014-04-11 23:11:59)
> Quoting Samuel Thibault (2014-04-11 22:27:09)
> > Justus Winter, le Fri 11 Apr 2014 09:32:30 +0200, a écrit :
> > > Previously, every userspace server implementing the device protocol
> > > filtered the device definitions to replace the device_t type with
> > > mach_port_send_t to make the device argument of device_open
> > > polymorphic.  Rather than doing that, which makes it impossible to use
> > > translation functions, fix the definition of device_open.
> > 
> > I don't know enough of MIG to be sure of the details: can this break
> > applications which would not be doing the sed part?
> 
> Yes.  However, I found every server implementing the device protocol
> doing it and most actually making good use of the extra
> mach_msg_type_name_t argument.

Ok, just to clarify this a little:

* This does not break the ABI, existing binaries will continue to
  function, so no update troubles.

* This does however make mig generate an extra argument of type
  mach_msg_type_name_t so that the server implementation may choose
  how the port in the out parameter 'device' is being handled.

In my opinion there is a bug in the mach definition.  20 years ago a
hacky workaround has been introduced into the Hurd [0].  I thought it
was time to just fix that.

0: 9c5cdb347079e9cb3bccbe041a0a2e834a87f80b

*If* there is a program out there that implements the device protocol,
and does not make the 'device' parameter of device_open polymorphic
like we do (in boot, and all the dde servers), then the fix is
trivial.  One just has to add an parameter of type
mach_msg_type_name_t *poly, and do *poly = MACH_MSG_TYPE_COPY_SEND.

Here is why I think it's a mistake not to make this out parameter
polymorphic:

Suppose we're implementing a device server.  Someone calls device_open
to open a device.  For this device we create a receive port p.  Now we
cannot just do *device = p because the type of device is device_t,
which is in fact mach_port_t, which is in fact
MACH_MSG_TYPE_COPY_SEND.  We cannot do that because we don't have a
send right to copy, just a receive right we created.

So the current definition of device_open breaks even the most straight
forward way to implement a device server.  In contrast, Hurds
dir_lookup gets this right:

routine dir_lookup (
        start_dir: file_t;
        RPT
        file_name: string_t;
        flags: int;
        mode: mode_t;
        out do_retry: retry_type;
        out retry_name: string_t;
        out result: mach_port_send_t);
                    ^ bam!

Justus