"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > I agree with Pierre, please provide some examples.
Ah yes, examples, examples. I've mostly been going by the following passage from an old archive mail about libchannel written by Marcus (http://people.debian.org/~terpstra/message/20020130.174030.17e4deb9.en.html) > For example, for a channel to a sound card raw audio device, you need > some way to set the sample bit rate. For a mouse device you might > want to set/clear dtr. For a keyboard you might want to set/clear raw > mode. I could use some concrete examples of how similar things are dealt with currently in the Hurd. Pointers to where to look for them are appreciated! But let's expand on the setting raw mode on keyboard one, which is simple enough. In linux this would look something like: ioctl (keyboard_fd, KDSKBMODE, K_RAW) Which the kernel delegates to the underlying keyboard device driver. The ioctl look-a-like: file_io_control (keyboard_file, KEYBOARD_SET_MODE, KEYBOARD_RAW) Which channelio recieves and calls some libchannel function that delegates it to the device channel class. And the hurdish one remote procedure per control procedure: keyboard_set_mode (keyboard_file, KEYBOARD_RAW) Which channelio recieves, but cannot handle so it delegates it to libchannel's demuxer which finds the implementing code, possibly by loading a module. > I suspect that if an object implements a wider interface, then the > added methods should be written up as a regular mig interface file. > That's what mig is there for: the dirty work. Yes, this is what I feel aswell. I'm was just a bit daunted by circumventing the mig demuxer but it seems this is fairly straight forward. > As the new routines extend the old interface, just call the basic > demuxer from your extended demuxer and then installer your extended > demuxer in the server loop. Look at how, e.g., > ports_manage_port_operations_multithread is used. > > Neal Thanks for the pointer, this is exactly what I was looking for! I'm currently thinking that each control interface should provide it's own demuxer that also takes a function pointer table and the channel as parameters. The only thing the stubs must do is call the function on the table that implements the procedure and add the channel to the it's parameters. Channel classes can then provide a list of demuxer, function table pairs of the control interfaces implemented and libchannel's demuxer will simply delegate to these. A get/set keyboard mode interface would look something like this: struct keyboard_control_if { error_t (*get_mode) (channel_t*, *int) error_t (*set_mode) (channel_t*, int) }; /* Server stubs. */ error_t keyboard_S_get_mode (int *mode) { if (iface->get_mode) return iface->get_mode (channel, mode) return EOPNOTSUPP; } error_t keyboard_S_set_mode (int mode) { if (iface->get_mode) return iface->get_mode (channel, mode) return EOPNOTSUPP; } int keyboard_demuxer (mach_msg_header *in, mach_msg_header *out, channel_t *channel, void* anon_iface) { keyboard_interface_t iface = anon_iface; return keyboard_server (in, out); /* mig generated demuxer. * } This seemed like a good idea until I realised I don't know how to get CHANNEL of IFACE from keyboard_demuxer to the stubs without circumventing ketboard_server. :-( Any suggestions? Cheers, Fredrik _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
