Re: io_select question

[Marcus Brinkmann]

At Sat, 24 Jul 2004 21:27:50 +0200,
Marco Gerards wrote:
> While I was implementing io_select for my netfs translator I noticed
> something really strange.  The io_select definition for libtrivfs and
> that for other translators (like libnetfs) are different.  An example:
> 
> error_t
> netfs_S_io_select (struct protid *user,
>                  int *type)
> 
> 
> kern_return_t
> trivfs_S_io_select (struct trivfs_protid *cred,
>                   mach_port_t reply,
>                   mach_msg_type_name_t replytype,
>                   int *seltype)
> 
> This is caused by:
> 
> routine io_select (
>       io_object: io_t;
> #if defined (REPLY_PORTS) || defined (IO_SELECT_REPLY_PORT)
>       replyport reply: sreply_port_t;
> #else
>       ureplyport reply: mach_port_make_send_t;
> #endif
>       waittime timeout: natural_t;
>       inout select_type: int);
> 
> 
> I don't understand what the exact differences are and why this is
> required.
> 
> Is there something I need to know about writing a server that
> implements io.defs, considering the differences that exist.

The replyport keyword in the mig definition allows you to get at the
raw reply port from the message sender in the server stub function.
Sometimes you need this for low-level manipulation (I think it is used
to stuff away the port in some structure for later reply, ie just
before you return ENOREPLY or so---I forgot the details, but if you
look at some code which actually uses this argument, it should become
clear).  I don't remember what ureplyport does (but I still have a mig
manual lieing around somewhere I could check or give to you).

The way io.defs is written, if you enable reply ports, it is enabled
for all interfaces.  So if you need it for one function, you get it
everywhere.  As libtrivfs is a library, this means that if you need it
in one translator using trivfs, the argument pops up just everywhere,
mostly unused.

For netfs, apparently nobody ever needed it, so it's not used, and
doesn't appear in the server stub interface.

In general, you don't need to worry about it unless you need it.  And
if you are lucky, you won't.

Marcus