Jeff Garzik wrote:
Ben Greear wrote:
I would also be open to moving the VLAN ioctls over into the
ethtool ioctl space, but that just exchanges one magic ioctl for
another...
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.
Actually, VLANs map very well to a per-interface API, since VLANs are
interfaces and reside on other interfaces.
Opening a socket and just ioctl'ing away isn't terribly scalable in the
long run, either. Consider all the applications that could legitimately
claim they need a SIOCxxx ioctl assignment, just for their little slice
of the networking world. Further, consider that all an ioctl is is a
My assumption is that adding a new ethtool message (or vlan ioctl message
to the existing VLAN ioctl call) does not cause new emulation problems.
Is that true?
I'll poke around and see what I can come up with.
I'm interested in seeing the result. I've never found a simple
example of something using the netlink api, and if it can be done,
then I'll probably convert.
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
|