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

Ihar 'Philips' Filipau
2004-09-01T15:29:30Z

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.