[Top][All Lists]

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

ioctl emulation (was: Re: GSoC libchannel project draft)

From: olafBuddenhagen
Subject: ioctl emulation (was: Re: GSoC libchannel project draft)
Date: Mon, 26 Mar 2007 16:16:23 +0200
User-agent: Mutt/1.5.13 (2006-08-11)


On Fri, Mar 23, 2007 at 09:13:09PM +0100, Richard Braun wrote:

> The second and most important point you didn't mention in your
> proposal concerns ioctls. Unlike block devices, there are lots of
> ioctls on character devices, and unlike a common Unix like system, GNU
> Mach doesn't handle ioctls. The problem here is that some ioctls
> expect a pointer and a size, but the current ioctl() implementation is
> unable to know that the parameter passed is a pointer and requires
> special handling. A kernel has enough control to handle this once it
> gets the pointer, but in the Hurd, the server can't do much with just
> a pointer and no data. The current trick is to implement some hooks
> directly in the C library (such as fioctl() in hurd/hurdioctl.c). Each
> "complex" ioctl must have such a hook, and this is painful.
> Implementing libchannel could be the occasion to find a generic
> solution to this problem.

Note that conceptually, libchannel (like libstore) is only a mostly
transparent optimisation happening in the background -- semantically,
you are just layering individual channel translators (or store

Using libchannel to translate from ioctls to proper RPC interfaces
doesn't really fit in this concept. While it also needs some way to load
modules into the client process (through libc in this case), the
requirements are pretty different. For one, it would explictely rely on
the module getting pulled in, which is very different from the concept
of transparent optimisation.

Also, with libchannel (like libstore), the program using it is aware of
channels, talking to the channell interface directly; and the actual
libchannel modules process this and output to a channel again if it's
stacked, or to something else if the channel ends here (with a kernel
device for example.) ioctl emulation on the other hand requires
translation *from* a different interface *to* channels (or stores or yet
something different, depending on the device type).

Last but not least, ioctl emulation doesn't really require stacking -- I
doubt there is much point in loading more than one emulation module per

I still think that ioctl emulation should use a mechanism for loading
modules within libc (as I suggested long ago), but this has really
nothing to do with libchannel.


reply via email to

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