[Top] [All Lists]

Re: [bonding] Add basic support for dynamic configuration of bond interf

To: Jeff Garzik <jgarzik@xxxxxxxxx>
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Sun, 11 Jan 2004 14:51:23 -0800
Cc: Amir Noam <amir.noam@xxxxxxxxx>, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, hadi@xxxxxxxxxx
In-reply-to: <>
Organization: Candela Technologies
References: <> <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
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

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 Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>