Server provided ioctl handler details

[Carl Fredrik Hammar]

Hi,

I've gotten a basic implementation of server provided ioctl handlers
working.  In which I unconditionally load a server provided module
containing the handlers on every call to ioctl, and then immediately
unload the module.  I would like to discuss some details of the current
implementation.

Currently, attempts to handle a ioctl are done in the following order:

* Use server ioctl handler
* Look up a glibc ioctl handler
* Translate ioctl into an RPC

This allows the server ioctl handler to override glibc's ioctl handlers.
The question is whether this functionality is useful, it could be
potentially confusing if the well established ioctls defined by glibc
are overridden.  I tend to think that since the ioctl handler is provided
by a trusted user, we can trust it to do the sane thing whatever that
turns out to be.  ;-)

The server module provides a single handler, which has essentially
the same signature as ioctl() itself, e.g it takes a file descriptor,
a request number, and a void pointer as arguments and is expected to
return -1 and set errno on error.  This is the same as the glibc provided
ioctl handlers.

While a module can only provide a single handler, it is easy to see that
it can forward the call to other handlers if necessary.  But I'm going
to try to handle it the same as glibc's handlers, so that the handlers
also could be used by simply linking it to the application itself.

I'm also considering allowing the server to specify several modules
containing ioctl handlers.  This would be useful if we decide to use
code-blessers since in that case it would be impossible for an untrusted
user to provide a trusted module that aggregates several trusted handlers.

But then again a device that implements ioctls from several device classes
are probably very exotic (at least when excluding those already defined
by glibc).  What do you think?

Regards,
  Fredrik