Re: f_ops flag to speed up compatible ioctls in linux kernel
From: Ihar 'Philips' Filipau
Date: Wed Sep 01 2004 - 10:31:33 EST
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/