Re: f_ops flag to speed up compatible ioctls in linux kernel

Roland Dreier
2004-09-01T17:25:11Z

This thread raises the issue of the best way for a driver to handle
commands from userspace. The typical situation is where the driver
needs to process commands from multiple processes and return a status
for each command.

I happen to work on the same type of drivers as Michael (InfiniBand),
and there are a fairly large number of operations that userspace would
like to call into the kernel for. User applications ask the kernel
driver to do things like "create completion queue." One would like to
make this call in a clean, simple, efficient way.

I can think of four ways to do this:

- ioctl on char device:
Nice because it is synchronous and allows for the kernel to
return a status value easily. Has a well-defined mechanism for
handling 32-bit/64-bit compatibility. Unfortunately ioctl
methods run under the BKL.

- read/write on char device:
OK, except requires some mechanism (tag #) for matching requests
and responses. Nowhere clean to put 32/64 compatibility code.

- netlink:
Similar to read/write except it adds the possibility of dropping
messages.

- syscall:
Syscalls are great in some ways. They are the most direct way
into the kernel, they allow

However: syscalls can't be added from modules; it's (quite
correctly) very hard to get new syscalls added to the kernel;
every arch numbers its syscalls differently. Let's forget about
syscalls.

ioctls end up looking like the least bad solution, although I'm open
to other opinions and I'd love to hear better ideas. I'd be happy
with a policy of only accepting ioctls that are sparse and 32/64 clean
and generally maintainable-looking, but I don't think driver authors
have much alternative to ioctl right now.

Thanks,
Roland