Re: [Bonding-announce] [PATCH SET][bonding] cleanup

	[removed bonding-announce from cc:]

On Thursday 25 September 2003 07:47 pm, Chad N. Tindel wrote:

quoted

quoted

patch 4 - remove dead code, old compatibility stuff and redundant
          checks.

I'm a bit concerned about doing some of this stuff in the 2.4
series.  That compatibility stuff is there for a reason, and was
set to be removed in 2.6.  Perhaps we shouldn't be doing stuff this
drastic until 2.6 because of the risk of breaking users.

That's the word I got from Jay in response to the " [Kernel-janitors] 
old ioctl definitions in 2.5" thread.

quoted

Jay Vosburgh [off-list ref] wrote:
I was going to add it on to the end of the clean up set, but
if you want to do it, go ahead.  Nobody seems to have objected to
removing the _OLD stuff, which I view as a good thing.

	My thinking here is that any ifenslave old enough (two years
or more) to still be using the OLD ioctl values is unlikely to work
with the current kernel driver, and if somebody did try it, it's
better to have the call fail outright than perform weird and
mysterious rituals in kernel memory.  I have trouble envisioning an
scenario where a user would be using the latest 2.4.23 kernel, but an
ifenslave from, what, 2.2.15? 2.4.5? or so.

	Separately, recent ifenslaves have compatibility code within
them to cover the great "ifenslave calling sequence change" from April
or so.  As much as I love the sleek new slimmed down ifenslave, I'm
not absolutely sure we can nuke that compatibility stuff within
ifenslave.  I really, really wanna, but I'm not sure if it will cause
problems for end users.  This is the upgrade scenario that prompted
the creation of the whole "ABI version" and compat stuff in the first
place; if we don't have to worry about that, then the simpler
ifenslave can be used, and I think the ethtool ABI version hack can go
away (since we wouldn't need an ABI version if there's only one).

	Comments?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

On Thursday 25 September 2003 08:33 pm, Jay Vosburgh wrote:

	Separately, recent ifenslaves have compatibility code within
them to cover the great "ifenslave calling sequence change" from
April or so.  As much as I love the sleek new slimmed down
ifenslave, I'm not absolutely sure we can nuke that compatibility
stuff within ifenslave.  I really, really wanna, but I'm not sure
if it will cause problems for end users.  This is the upgrade
scenario that prompted the creation of the whole "ABI version" and
compat stuff in the first place; if we don't have to worry about
that, then the simpler ifenslave can be used, and I think the
ethtool ABI version hack can go away (since we wouldn't need an ABI
version if there's only one).

	Comments?

I think I better leave this for Amir to answer. He's our ABI expert 
and this needs carefull consideration, especially now that he's 
working on enhancing ifenslave's capabilities for the hot operation 
stuff. However, he won't be able to do that before Monday since we're 
going out on a long weekend - it's holiday season over here.

-- 
| Shmulik Hen   Advanced Network Services  |
| Israel Design Center, Jerusalem          |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp.  |

quoted

quoted

I was going to add it on to the end of the clean up set, but
if you want to do it, go ahead.  Nobody seems to have objected to
removing the _OLD stuff, which I view as a good thing.

	My thinking here is that any ifenslave old enough (two years
or more) to still be using the OLD ioctl values is unlikely to work
with the current kernel driver, and if somebody did try it, it's
better to have the call fail outright than perform weird and
mysterious rituals in kernel memory.  I have trouble envisioning an
scenario where a user would be using the latest 2.4.23 kernel, but an
ifenslave from, what, 2.2.15? 2.4.5? or so.

I was specifically told by David Miller that we are not to break binary
compatibility within a 2.4 release.  Such things had to wait until 2.5 
or later.  We can not require a user to upgrade their ifenslave within a 2.4
series kernel just to keep using the same functionality they were using in 
2.4.1.  Obviously we can require them to upgrade in order to keep using
new functionality.  So the _OLD stuff needs to stay in the 2.4 kernel.  If
this was brought up in an earlier thread, then I just missed it.

Chad

Hi !

On Thu, Sep 25, 2003 at 05:13:00PM -0400, Chad N. Tindel wrote:
 

I was specifically told by David Miller that we are not to break binary
compatibility within a 2.4 release.  Such things had to wait until 2.5 
or later.  We can not require a user to upgrade their ifenslave within a 2.4
series kernel just to keep using the same functionality they were using in 
2.4.1.

I strongly agree. I have been facing this problem and it was really a pain. I
used the last bonding version which didn't define the ABI version, together
with the associated ifenslave, but when the need to upgrade to plain 2.4.22
came in, I had the surprize of getting a non-working bonding because this
intermediate ifenslave. Well, I upgraded it to latest version, which prevents
me from downgrading to the previous kernel because it has ABIv2 with no version,
so the newer ifenslave thinks it's an ABIv1. So the result is a symlink with
two versions of ifenslave on the disk, just in case I have to downgrade.

Although I agree it's clearly my fault and I should have been more careful, I
prefer to warn everyone about the consequences this might have on production
systems. Schmulik has done quite a great job here, and I believe most of it
should be integrated, but we have to carefully test each combination of old/new
ifenslave with old/new driver if we don't want to break some setups or prevent
admins from downgrading if something goes wrong.

Cheers,
Willy