Creating new interfaces for specific servers

[Ludovic Courtès]

Hi,

I'm wondering about the policy for the Hurd with respect to the creation of
new interfaces/RPCs. There was a thread, some time ago (see below), where
Marcus said that ioctls were a "horrible hack".

So, how should the Hurd handle functions required by specific servers where
the existing interfaces (io, fs, socket¸ etc.) are not sufficient? For
example, for an audio cd translator, it would be necessary to create a
specific interface for playing CDs and so on.

>From my understanding, the current policy is to try not to have too many
interfaces and to try as much as possible to use the existing one. Is it
correct? If yes, to which extend should people avoid creating new interfaces?

Thanks,
Ludovic.

On Tue, Mar 12, 2002 at 05:42:28PM +0100, Marcus Brinkmann wrote:
> 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