To: viro@parcelfarce.linux.theplanet.co.uk
Cc: discuss@x86-64.org, linux-kernel@vger.kernel.org
Subject: Re: f_ops flag to speed up compatible ioctls in linux kernel
References: <20040901072245.GF13749@mellanox.co.il>
	<20040901073218.GQ16297@parcelfarce.linux.theplanet.co.uk>
From: Roland Dreier <roland@topspin.com>
Date: Wed, 01 Sep 2004 08:55:11 -0700
In-Reply-To: <20040901073218.GQ16297@parcelfarce.linux.theplanet.co.uk> (viro@parcelfarce.linux.theplanet.co.uk's
 message of "Wed, 1 Sep 2004 08:32:19 +0100")
Message-ID: <52zn4a0ysg.fsf@topspin.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2029
Lines: 49

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/