From: Jeff Garzik <jgarzik@pobox.com>
To: Amir Noam <amir.noam@intel.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>,
bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
Date: Sat, 10 Jan 2004 20:34:48 -0500 [thread overview]
Message-ID: <4000A838.5040808@pobox.com> (raw)
In-Reply-To: <200401081819.54484.amir.noam@intel.com>
Amir Noam wrote:
> The following patch sets provide basic support for future bonding
> operations (specifically for dynamic configuration of bonding
> interfaces).
>
> This is done by adding two new bonding ioctls: one for deviceless
> commands (an ioctl hook) and one for device oriented commands. Like
> ethtool, the first u32 value in the data structure will indicate the
> exact sub-command to be executed.
>
> The sets are against the latest netdev-2.4 and net-drivers-2.5-exp
> trees.
I don't disagree with the overall goal of these patches, but I think we
might need to pause a bit, and consider how best to configure, add, and
remove bonding interfaces, if we are coming up with a new interface.
For configuration tasks that occur outside the scope of a single bonding
interface (i.e. a single struct net_device), you need a separate entity
from a socket ioctl. It's not ideal at all to configure N objects using
a special ioctl ... when opening one of said objects :)
I would suggest a simple character device (misc_register), and let the
userland application configure settings unrelated to a single object.
For a configuring state related to a _single_ bonding interface (i.e. a
single net_device), socket ioctls are OK.
Jeff
next prev parent reply other threads:[~2004-01-11 1:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-08 16:19 [bonding] Add basic support for dynamic configuration of bond interfaces Amir Noam
2004-01-11 1:34 ` Jeff Garzik [this message]
2004-01-12 17:23 ` Ben Greear
[not found] <E6F7D288B394A64585E67497E5126BA601F991D1@hasmsx403.iil.intel.com>
2004-01-11 14:28 ` Amir Noam
2004-01-11 18:30 ` jamal
2004-01-11 19:39 ` Jeff Garzik
2004-01-11 21:34 ` Ben Greear
2004-01-11 21:59 ` Jeff Garzik
2004-01-11 22:50 ` jamal
2004-01-11 22:51 ` Ben Greear
2004-01-12 0:13 ` Jason Lunz
2004-01-13 2:34 ` Jeff Garzik
2004-01-12 12:38 ` Andi Kleen
2004-01-12 13:51 ` jamal
2004-01-12 15:04 ` Andi Kleen
2004-01-13 12:28 ` jamal
2004-01-13 12:39 ` Andi Kleen
[not found] <E6F7D288B394A64585E67497E5126BA601F991D3@hasmsx403.iil.intel.com>
2004-01-14 15:00 ` Amir Noam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4000A838.5040808@pobox.com \
--to=jgarzik@pobox.com \
--cc=amir.noam@intel.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=fubar@us.ibm.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.