Re: ioctl's handling with a trivfs translator

[Marcus Brinkmann]

On Tue, Mar 12, 2002 at 03:30:33PM +0100, Ludovic Courtès wrote:
> I am wondering whether there is a trivfs callback corresponding to a libc
> ioctl() call and which one it could be?

Actually, no there is no such call.  If there should be one is another
matter, but I don't think so.  Let me explain:

ioctls are catched in the C library.  The C library then checks if that
ioctl is special cased in hurd/hurdioctl.c, and if it is, it calls that
function.  Otherwise, it will try to use the ioctl number to generate an
RPC.  The 32 bits in the ioctl number encode the subsystem, the message id,
and the message arguments!  So that is very clever code in
sysdeps/mach/hurd/ioctl.c and only works for the most simple ioctls which
only take a couple of simple arguments.  ioctls which _break_ the ioctl
interface and return large amounts of data, like for example SIOCGIFCONF, or
which have other side effects in the user program, can not be handled by
simple RPCs, and need a special case in hurd/hurdioctl.c

One of the reason to not have a ioctl call is that not all traditional UNIX
ioctls can be dealt with by simple rpcs, it needs support in the user task. 
Another is cleanliness:  ioctl is a horrible hack to avoid designing proper
interfaces, or maybe to save syscall numbers.  In the Hurd, we have a proper
IPC system, so we don't really need ioctls.  But we need them anyway for
compatibility, so we have them, but then a ioctl id corresponds to an RPC,
or to a special case in the C library.

> So, what happens when a user program calls ioctl()? In order to be compatible

I hope the above explanation helps a bit, ask if something is unclear.

> with some Linux code (like audio cd players for instance which use ioctl() 
> calls
> on the cdrom device), it might be interesting to have translators responding
> to ioctl's in the same way as the Linux kernel.

Well, if the ioctl interface you want to emulate is simple enough, you can
get away by using the macros in <bits/ioctls.h> to map the ioctl to an RPC. 
But usually we do this onyl for well established ioctls and for
compatibility with legacy code.  For example, we don't have termio because
there is termios in POSIX, which programs should use.

I think for specialised interfaces, only used by one or two applications, it
might make sense for you to develop a proper, usable RPC interface for your
server (in case the existing filesystem and IO interface is not sufficient,
extend it with a new subsystem) and then port the Linux specific
applications to this new interface, maybe by writing a small intermediate
layer that is OS specific.  It really depends on the particular case. 
People should use libraries, not ioctls, even if the underlying system only
provides a ioctl interface for the functions.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de