Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[kaih@khms.westfalen.de (Kai Henningsen)]

torvalds@transmeta.com (Linus Torvalds)  wrote on 20.05.01 in <Pine.LNX.4.21.0105202005070.8426-100000@penguin.transmeta.com>:

> 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