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

Re: [Bonding-devel] Re: [bonding] compatibilty issues

[Jay Vosburgh]

>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 say:

	Toast the whatever_OLD guys (the backwards compat ioctls) in
both 2.4 and 2.6.  Backwards compatibility is good, but there are
limits, and I think these have reached their limit.

	Keep the ABI versioning stuff in both 2.4 and 2.6.  As I've
said, that slimmed down ifenslave really makes my mouth water in
anticipation, but I don't think we can escape our fate that easily
just yet.  Someday....

	Any comments from the usual gang?

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

	I'm still looking through the patch set; I generally like what
I see, and think it's probably all good to go for 2.6 (modulo the
various changes we're discussing).  I was thinking the same for 2.4,
but then I had a long chat with Chad, and now he's got me worried
about potential stability problems from such a large set of changes.

	I'm wondering if we should apply the set to 2.6 first, and
give it some air time in that environment before going on to 2.4.

	The only nit I have thus far is that you need to remove the
documentation for multicast_mode along with the option (which I've
mentioned before somewhere; just reminding, not whining).  Or perhaps
better, leave some text explaining that the option is no longer
supported (and why).  Chad and I were discussing whether or not we
should leave a dummy option (that silently does nothing, or prints
some sort of useful message) so that end users don't get a warning if
they supply a multicast_mode module parameter.  If there is no
paramter at all, users get a warning from modprobe (or insmod or
somewhere) that the option does not exist, but the insmod does
complete.

	Another possibility would be a parameter that does nothing,
unless the user selects a setting that conflicts with the calculated
choice.  In that case, fail the insmod.  This way, end users won't get
a warning as long as they're doing the right thing.  I haven't decided
if I like this idea just because it seems kind of clever, or because
it would actually be the right thing to do.

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

	Unfortunately, no, it doesn't seem to be feasible to keep the
2.4 and 2.6 source bases identical (which I was pretty jazzed about).
I still want to try to keep them as close as is reasonable, which is
why I'd like to put the full cleanup set into 2.4 if we can.

	-J

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

Re: [Bonding-devel] Re: [bonding] compatibilty issues

[Chad N. Tindel]

> 	Toast the whatever_OLD guys (the backwards compat ioctls) in
> both 2.4 and 2.6.  Backwards compatibility is good, but there are
> limits, and I think these have reached their limit.
> 
> 	Keep the ABI versioning stuff in both 2.4 and 2.6.  As I've
> said, that slimmed down ifenslave really makes my mouth water in
> anticipation, but I don't think we can escape our fate that easily
> just yet.  Someday....
> 
> 	Any comments from the usual gang?

My recommendations are more towards the middle than either end.  I would
like to see us get rid of the _OLD ioctls in the 2.6 kernel specifically 
because it uses the SIOCDEVPRIVATE ioctls.  This only breaks redhat if they
are shipping with a 3 year old ifenslave.  I would like to see them stay
in 2.4 for the rest of the 2.4 tree specifically so that people who want
to run on 3 year old systems can continue to do so without us breaking
their world.

Now, that being said... who you really need buyoff from is David Miller and
Jeff Garzik, since they need to be OK with whatever you implement.  Those 
guys tend to be more conservative than me, so if you can convince them
of your plan then I won't argue with it.

> 	I'm still looking through the patch set; I generally like what
> I see, and think it's probably all good to go for 2.6 (modulo the
> various changes we're discussing).  I was thinking the same for 2.4,
> but then I had a long chat with Chad, and now he's got me worried
> about potential stability problems from such a large set of changes.

This was just a general comment.  2.4 is supposed to be a stable tree...
that is, once 2.6 becomes real, we should make a concerted effort to 
not put new features into 2.4 in an effort to keep it stable.  There are
plenty of customers in the real world that won't be moving to 2.6 for 1-2 
years, and such people are not concerned with getting the newest features...
they're most concerned with having something that is supportable and doesn't
break.

> 	I'm wondering if we should apply the set to 2.6 first, and
> give it some air time in that environment before going on to 2.4.

That doesn't seem like a bad idea to me.

> 	Unfortunately, no, it doesn't seem to be feasible to keep the
> 2.4 and 2.6 source bases identical (which I was pretty jazzed about).
> I still want to try to keep them as close as is reasonable, which is
> why I'd like to put the full cleanup set into 2.4 if we can.

Its highly un-reasonable to keep the 2.4 tree in sync with 2.6 in the
long run.  Like I said, at some point, we should stop putting new features
into 2.4... and this will be the same point at which they begin to diverge
rapidly.  Now, all that said... I don't think we're at that point yet, and 
so I have no objection with going through the pain of keeping them in
sync still.

Chad

Re: [Bonding-devel] Re: [bonding] compatibilty issues

[David S. Miller]

On Tue, 30 Sep 2003 17:36:50 -0400
"Chad N. Tindel" <chad@tindel.net> wrote:

> My recommendations are more towards the middle than either end.  I would
> like to see us get rid of the _OLD ioctls in the 2.6 kernel specifically 
> because it uses the SIOCDEVPRIVATE ioctls.
 ...
> I would like to see them stay in 2.4 for the rest of the 2.4 tree
> specifically so that people who want to run on 3 year old systems
> can continue to do so without us breaking their world.

I think this is fine, personally.

I defer to Jeff for final judgment, he should be allowed to chime in
at least once more.