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 _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-hurd
