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: <CAHashqCrRq3z_bwddy3Y3+t+hmA4oN3hndmsTKUDNc73U=c3Gg@mail.gmail.com>
Date:	Wed, 3 Aug 2011 15:03:17 -0400
From:	Andy Gospodarek <andy@...yhouse.net>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	Jay Vosburgh <fubar@...ibm.com>, netdev@...r.kernel.org
Subject: Re: bonding and ifenslave version.

On Wed, Aug 3, 2011 at 2:43 AM, Nicolas de Pesloüan
<nicolas.2p.debian@...il.com> wrote:
> Le 02/08/2011 22:06, Nicolas de Pesloüan a écrit :
>>
>> Commit 655f8919d549ad1872e24d826b6ce42530516d2e
>>     bonding: add min links parameter to 802.3ad
>>
>> and commit ebd8e4977a87cb81d93c62a9bff0102a9713722f
>>     bonding: add all_slaves_active parameter
>>
>> introduced new options to bonding, but didn't provide the documentation
>> for those options.
>>
>> Signed-off-by: Nicolas de Pesloüan<nicolas.2p.debian@...e.fr>
>> ---
>
> Jay, Andy,
>
> While working at this patch, I noticed that the bonding driver version
> wasn't bumped up at the time those options were introduced.
>
> 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.

> 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.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ