netdev
[Top] [All Lists]

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

To: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Sun, 11 Jan 2004 16:59:10 -0500
Cc: Amir Noam <amir.noam@xxxxxxxxx>, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, hadi@xxxxxxxxxx
In-reply-to: <4001C158.6040103@candelatech.com>
References: <E6F7D288B394A64585E67497E5126BA601F991D1@hasmsx403.iil.intel.com> <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
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.

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 message sent to the kernel driver, perhaps sending and/or receiving some data. :)

ioctls are a pain for 32/64-bit emulation layers too. It seems much easier to define a netlink protocol family of some sort and communicate that way.

I'll poke around and see what I can come up with.

        Jeff




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