[Top] [All Lists]

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

To: Jason Lunz <lunz@xxxxxxxxxxxx>
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Mon, 12 Jan 2004 21:34:06 -0500
Cc: netdev@xxxxxxxxxxx
In-reply-to: <slrnc03pm8.3sp.lunz@orr.homenet>
References: <> <> <> <> <> <slrnc03pm8.3sp.lunz@orr.homenet>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Jason Lunz wrote:
jgarzik@xxxxxxxxx said:

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 :)


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