Jason Lunz wrote:
The key question is what is the best interface for userland to configure
in-kernel information -that is unrelated to a specific interface-.
ethtool ioctl space doesn't apply, because that's a per-interface API.
ethtool is just as bad as brctl or any of the others. From (userland)
ethtool contains only per-interface operations.
One should not stuff extra-interface operations onto an ioctl, IMO.
calling a spade a spade, and all that. I don't see how that's any better
than brctl. The per-interface only comes into it when you copy a dev
name into a struct ifreq, but that doesn't associate the fd with the
interface in any way. You could go ahead and issue another ioctl on the
same fd for a different interface.
I make it no secret that I dislike ioctls in general, and would like to
move away from dependence on ioctl (and procfs) magic... Ideally one
should be able to maintain and coordinate the ABI of one's own driver,
without always going through a central authority for some magic number.
Linux is (should be) more dynamic than that. It's a hotplug,
decentralized world :)