netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>,
	Veaceslav Falico <vfalico@redhat.com>, <netdev@vger.kernel.org>,
	Jay Vosburgh <fubar@us.ibm.com>
Subject: Re: [PATCH] bonding: Don't allow mode change via sysfs with slaves present
Date: Tue, 15 Nov 2011 19:33:17 +0000	[thread overview]
Message-ID: <1321385597.2744.11.camel@bwh-desktop> (raw)
In-Reply-To: <4EC2BC6D.9000304@gmail.com>

On Tue, 2011-11-15 at 20:24 +0100, Nicolas de Pesloüan wrote:
> Le 15/11/2011 18:00, Andy Gospodarek a écrit :
> > On Tue, Nov 15, 2011 at 05:44:42PM +0100, Veaceslav Falico wrote:
> >> When changing mode via bonding's sysfs, the slaves are not initialized
> >> correctly. Forbid to change modes with slaves present to ensure that every
> >> slave is initialized correctly via bond_enslave().
> >>
> >> Signed-off-by: Veaceslav Falico<vfalico@redhat.com>
> >
> > Looks good.  This behavior forces someone who wants to change to mode to
> > go through steps that are almost as destructive as when module options
> > are used to configure the mode.  I do not see a problem with this.
> 
> Except the fact that is enforce one more constraint on the exact order one should write into sysfs 
> to setup a bonding interface. We already have many such constraints and probably don't need more.

From the administrator perspective, perhaps.  From the developer
perspective, the current flexibility of bonding makes it very difficult
to test and maintain.

> Currently, it is possible to enslave slaves before selecting the mode. The ifenslave-2.6 package 
> from Debian currently enslave slaves before setting the mode and would break with this change.
> 
> NAK.

It sounds like this feature has to be kept and fixed, then.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

  reply	other threads:[~2011-11-15 19:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 16:44 [PATCH] bonding: Don't allow mode change via sysfs with slaves present Veaceslav Falico
2011-11-15 17:00 ` Andy Gospodarek
2011-11-15 19:24   ` Nicolas de Pesloüan
2011-11-15 19:33     ` Ben Hutchings [this message]
2011-11-15 19:35     ` Andy Gospodarek
2011-11-15 20:02       ` Nicolas de Pesloüan
2011-11-15 20:47         ` Andy Gospodarek
2011-11-16 12:02           ` Nicolas de Pesloüan
2011-11-16 22:02             ` Andy Gospodarek
2011-11-17  1:16               ` Flavio Leitner
2011-11-17 21:28               ` Nicolas de Pesloüan
2011-11-15 21:04     ` Veaceslav Falico
2011-11-17 21:04 ` David Miller
2011-11-17 22:36   ` Nicolas de Pesloüan
2011-11-18  0:32     ` David Miller

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=1321385597.2744.11.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=andy@greyhouse.net \
    --cc=fubar@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.2p.debian@gmail.com \
    --cc=vfalico@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).