bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libchannel] Control procedures


From: Carl Fredrik Hammar
Subject: Re: [libchannel] Control procedures
Date: Tue, 10 Jul 2007 16:41:38 +0200
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1.50 (gnu/linux)

"Neal H. Walfield" <neal@walfield.org> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]