Re: [bonding] compatibilty issues

Re: [bonding] compatibilty issues

[Chad N. Tindel]

[-- Attachment #1: Type: text/plain, Size: 81 bytes --]

Forwarding, as I forgot to include the list on the original 
distribution.

Chad

[-- Attachment #2: Type: message/rfc822, Size: 2380 bytes --]

From: "Chad N. Tindel" <chad@tindel.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>, "Hen, Shmulik" <shmulik.hen@intel.com>, "Noam, Amir" <amir.noam@intel.com>, "Mendelson, Tsippy" <tsippy.mendelson@intel.com>, "Marom, Noam" <noam.marom@intel.com>
Subject: Re: [bonding] compatibilty issues
Date: Mon, 29 Sep 2003 19:24:44 -0400
Message-ID: <20030929232444.GA93323@calma.pair.com>

> Chad N. Tindel wrote:
> >2.  Once a user upgrades to 2.6, they forego all hope of forward 
> >compatibility.
> >They may be required to upgrade ifenslave. 
> 
> Not correct.  When I am testing patches people send to me, I am 
> literally booting back and forth into 2.4 and 2.6 on an hour-by-hour 
> basis.  2.4 ifenslave must continue to work under a 2.6 kernel.

This directly contradicts what I was told by David Miller when we first
integrated bonding into 2.4 back in the 2.4.9 timeframe.  So, what I would
like from you then is a statement saying for how long this support must
continue.  Does the 2.8 ifenslave have to work for 2.4?  Or is it simply
an off by one problem?  That is, 2.8 ifenslave will have to work for 
a 2.6 kernel as well, but no more?  

Are all the other utilities having to do this too?  raidhotadd will continue
to work both for 2.4 and 2.6?  

> Rusty tried this with module-init-tools, and it's a yucky solution.  For 
> this case, Red Hat updated the modutils package to support both 2.4 and 
> 2.6 kernels out of the box, same userland.

I agree its a yucky solution, but its better than saying that the Linux
Kernel 4.6 version of ifenslave has to work for all prior versions of 
bonding (2.4, 2.6, 3.0, 3.8, 4.0 etc..).  And it also seems better from
a code stability point of view too... I mean, if all we had some was scripting
nastiness and it meant that because our code in newer kernels was simpler, 
leaner, easier to work with and debug... that would seem like the proper
tradeoff to make.  No?

Chad

Re: [bonding] compatibilty issues

[Jeff Garzik]

Chad N. Tindel wrote:
>>Not correct.  When I am testing patches people send to me, I am 
>>literally booting back and forth into 2.4 and 2.6 on an hour-by-hour 
>>basis.  2.4 ifenslave must continue to work under a 2.6 kernel.
> 
> 
> This directly contradicts what I was told by David Miller when we first
> integrated bonding into 2.4 back in the 2.4.9 timeframe.  So, what I would
> like from you then is a statement saying for how long this support must
> continue.  Does the 2.8 ifenslave have to work for 2.4?  Or is it simply
> an off by one problem?  That is, 2.8 ifenslave will have to work for 
> a 2.6 kernel as well, but no more?  

Well, if that's David's sentiment, then I respectfully disagree with that.

You need to be conscious of what installations are out there.  Most 
kernel maintainers, myself and David included, are currently maintaining 
both 2.4 and 2.6 support because that's what people are using. 
Eventually time will pass, and 2.4 will (essentially) go unmaintained, 
and the kernel maintainers will focus their attention on 2.6 stable 
series, and development for 2.7.

At the user end of things, people are for the most part running 
2.4.x-based stuff, with perhaps some early adventures into 2.6.  So you 
can see the _common_ case for the near future is supporting both 2.4 and 
2.6 out of the box.

I'm realistic.  I'm not advocating that you support 2.2 through 2.8 
kernels in the same binary.  What I'm talking about is common sense -- 
you see 2.4 and 2.6 mixing in the field.  As I said, that's the common 
case for the near future.

The common case should be supported.   :)

	Jeff

Re: [bonding] compatibilty issues

[Chad N. Tindel]

> Well, if that's David's sentiment, then I respectfully disagree with that.

And in all actuality, I might have misunderstood it anyway.  ;-)

> I'm realistic.  I'm not advocating that you support 2.2 through 2.8 
> kernels in the same binary.  What I'm talking about is common sense -- 
> you see 2.4 and 2.6 mixing in the field.  As I said, that's the common 
> case for the near future.
> 
> The common case should be supported.   :)

Agreed.  Is there some point at which we can stop supporting 2.4 from the 2.6
ifenslave?  I mean, its kind of nebulous to just say the "common case"...
you gotta realize, most of us work in big companies like HP, IBM, Intel and
concepts of support life have real meaning to us.

This is a very interestng discussion.  Do you have any insights into what
the other parts of the kernel are doing wrt to this problem?

Chad

Re: [bonding] compatibilty issues

[David S. Miller]

On Mon, 29 Sep 2003 19:38:10 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> Well, if that's David's sentiment, then I respectfully disagree with that.

I really really really did intend to move these deprecated as fast as
possible.  This is because these bonding ioctls use SIOCDEVPRIVATE
values.

I don't think it's much of a burdon to remove their existence from
the 2.6.x copy of the driver, and I really wish you guys would do
this because then people would fix their tools.

You can very simply compile a copy of the tool that works with the
non-SIOCDEVPRIVATE ioctls we added to the bonding driver a LONG time
ago and it'll work with 2.4.x as well.  It doesn't break because
you made it work with the non-ambiguous ioctl values.

Re: [bonding] compatibilty issues

[Shmulik Hen]

Guys,

I'm going to need a ruling here :)
Re-creating those 19 trees each time is killing me and I would like to 
reduce the number of iterations to a minimum.
I'm currently working on putting back all compatibility stuff for 2.4. 
I would like to also get any input/reservations about other issues 
(besides compatibility and the multicast param) so I may get a chance 
to get them all in at once.

Once we get that settled, I can start working on a 2.6 version that 
also handles any compatibility issues (preferrably as the last patch 
of the series). I'm working in the assumption that 2.4-2.6 similarity 
is no longer an option for bonding.

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