lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Aug 2011 14:33:38 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org
Subject: Re: bonding and ifenslave version.

On Wed, 03 Aug 2011 22:38:03 +0200
Nicolas de Pesloüan  <nicolas.2p.debian@...il.com> wrote:

> Le 03/08/2011 22:07, Jay Vosburgh a écrit :
> > Nicolas de Pesloüan<nicolas.2p.debian@...il.com>  wrote:
> >> Le 03/08/2011 21:03, Andy Gospodarek a écrit :
> 
> >>> Distributions benefit from version numbers on userspace utils.  It
> >>> would probably be better to keep ifenslave's version number as it is
> >>> to help those maintaining those distro packages.
> >>
> >> As one of the maintainers for the ifenslave package on Debian, I perfectly
> >> understand the need for an upstream version, but as such, I expected the
> >> upstream version number to change when the file change... Version numbers
> >> in Debian use upstream version numbers when available and add a subversion
> >> number for Debian specific changes. I would expect to change the version
> >> number and not only the Debian subversion when the only change is a new
> >> upstream version.
> >
> > 	One thing to remember here is that currently very few (perhaps
> > no) distros use the ifenslave.c that comes with mainline.  The distros
> > I'm familiar with configure bonding via sysfs, either directly in
> > initscripts / sysconfig, or via a shell script ifenslave (which I
> > believe is what Debian has).  Many distros still install it in
> > /sbin/ifenslave, but it isn't used by the network configuration stuff.
> 
> The ifenslave package on Debian provide two things:
> 
> - The binary ifenslave, simply compiled from mainline ifenslave.c.
> - A plug-in for ifupdown to allow for bonding related options in /etc/network/interfaces. I can 
> confirm that this plug-in doesn't use the ifenslave command, but sysfs, since version 1.1.0-12 
> (current stable version of this package is 1.1.0-17).
> 
> > 	The ifenslave.c in mainline is pretty much just a legacy for
> > backwards compatibility; it has not had a bug fix since 2005 (a few typo
> > repairs since then), and no major functional changes since before the
> > git era.
> >
> > 	I was considering proposing feature removal for ifenslave.c and
> > the ioctl API to add and remove slaves, but some discussion a few months
> > ago indicated that there are apparently still some users out there (I'd
> > guess embedded of some variety).
> 
> Unfortunately, there exist *many* how-to that suggest to use ifenslave, causing many users to use it 
> instead of sysfs for bonding setup.
> 
> At least, we can:
> - update the bonding documentation to clarify that ifenslave is deprecated (and move most ifenslave 
> related stuffs at the end of the documentation);
> - possibly issue a warning when the API is used, suggesting to use sysfs instead.
> 
> I can take care of the documentation update if appropriate.
> 
> 	Nicolas.

Or I could just put a shell script that does the same thing in iproute.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists