netdev - Re: bonding and ifenslave version.

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]

Message-ID: <1718.1312402077@death>
Date:	Wed, 03 Aug 2011 13:07:57 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	=?ISO-8859-1?Q?Nicolas_de_Peslo=FCan?= 
	<nicolas.2p.debian@...il.com>
cc:	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org
Subject: Re: bonding and ifenslave version.

Nicolas de Pesloüan <nicolas.2p.debian@...il.com> wrote:

>Le 03/08/2011 21:03, Andy Gospodarek a écrit :
>
>>> I thought introducing a new option should cause the driver version to
>>> change. Am I right?
>>
>> When a significant change happens, we try to change the version
>> number.  The version number probably should have been changed when
>> those were added.  Inspecting the module options or sysfs parameters
>> indicate whether or not these patches were added, so it is less of a
>> priority than when some internal infrastructure (like moving to use
>> rx_handler) changes.
>>
>> I consider it more critical to change the bonding module version when
>> something changes that cannot be detected by inspecting the module or
>> sysfs parameters.  This is more helpful to users reporting problems.
>>
>
>Ok, 'sounds perfectly sensible to me, thanks.
>
>>> On a different but related topic, the version in
>>> Documentation/networking/ifenslave.c (1.1.0) didn't change since the git
>>> origin and probably since 2003.
>>>
>>> Arguably, none of the commit regarding this file introduced a significant
>>> change (with the possible exception of commit
>>> e6d184e33109010412ad1d59719af74755a935f4, [NET]: Fix ifenslave to not fail
>>> on lack of IP information). But if we never change a 3-level version number,
>>> whatever the level of change, this version number might be useless. Any
>>> comment?
>>>
>>>         Nicolas.
>>>
>>
>> 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.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).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
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