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

["Ihar 'Philips' Filipau" <filia@softhome.net>]

Ihar 'Philips' Filipau wrote:
> 
> P.P.S. Hm. Why not implement ioctl2()? which will be linked directly to 
> device by its driver? - numbering will be internal to driver, and 
> provide entry point into driver for user space applications. No one 
> likes mess with ioctl()s in Linux - no device driver developers, nor 
> users. But what is really needed - is just call into driver. Paramenter 
> - single pointer have being proved to be sufficient.
> 

   Ok. Now I recalled those mess with ioctl()s - someone have tryed to 
implement virtual methods from OO languages with file descriptors and 
miserably failed.

   I have never used ioctl()s for anything asides calling my drivers. I 
have seens people using ioctl codes for special functionality for block 
devices.

   Position "ioctl()s bad" is not related to drivers per se. People 
decided to not introduce another calls like eject_media(fd) or 
get_info(fd) - but instead implement ioctl() which will magically work 
on all fd's of block devices.
   That where mistake is. That the kind of ioctl()s, which are bad. 
ioctl() is for something what doesn't have interface. If something have 
stable interface - it must be moved over to sys/library calls.

   Instead of "painful ioctl()s" - I would rather start with solving 
this problem for standard devices: making a way to implement efficiently 
common functions for device classes. (terminals, block devices, network 
interfaces, etc). And start obsoleting/removing ioctl()s.

   I like aproach of *BSD - they routinely implement library/sys calls 
for things like that. I used if_*/getif* calls to find/operate network 
interfaces - it is much more usable & better documented, than Linux' 
bunch of magic ioctl()s (again) on _any_ network socket. Why on any? Why 
we cannot have special device to operate on list of interfaces?

   I believe people here on LKML identified problem incorrectly.