[EMAIL PROTECTED] (Linus Torvalds) wrote on 20.05.01 in
<[EMAIL PROTECTED]>:
> If we had nice infrastructure to make ioctl's more palatable, we could
> probably make do even with the current binary-number interfaces, simply
> because people would use the infrastructure without ever even _seeing_ how
> lacking the user-level accesses are.
>
> But that absolutely _requires_ that the driver writers should never see
> the silly "pass a random number and a random argument type" kind of
> interface with no structure or infrastructure in place.
Hmm.
So would it be worthwile to invent some infrastructure - possibly
including macros, possibly even including a (very small) code generator, I
don't really have any details clear at this point - that allows you to
specify an interface in a sane way (for example, but not necessarily, as a
C function definition, though that may be too hard to parse), and have the
infrastructure generate
1. some code to call ioctl() with these arguments
2. some other code to pick apart the ioctl buffer and call the actual
function with these arguments
preferrably so that (a) the code from 1 is suitable for use in libc or
similar places, (b) the code from 2 is suitable for the kernel, (c) most
(all would be better but may not be practical) existing ioctls could be
described that way?
(If so, the first task would obviously be to analyze existing code in
those places, and the actual structure of existing ioctls, to find out
what sort of stuff needs to be supported, before trying to design the
mechanism to support it.)
A variant possibility (that I suspect you'll like significantly less)
would be a data structure to describe the ioctl that gets interpreted at
runtime. I think I prefer specific code for that job. At least *some*
ioctls are in hot spots, and interpreting is slow. And that hypothetical
encapsulation certainly should not know the difference between fast and
slow interrupts^Wioctls.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
