Re: [bonding] compatibilty issues

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.

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

[Shmulik Hen]

On Wednesday 01 October 2003 10:05 am, David S. Miller wrote:
> 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.
>

So here is what I did in the meantime:
* Created a version for 2.4 that puts back all old compatibility stuff 
  that was removed either during the propagation set or the cleanup 
  set.
* Created a version for 2.6 that puts back just the compatibility 
  stuff that was removed in the propagation set (BOND_SETHWADDR, since 
  we got a complaint from a RH9 user).
* Removed the mention of the multicast param from the read-me.
* Raised the ABI version to 2 so the new ifenslave keeps propagating 
  IP settings to slaves for older drivers, and doesn't do that for new 
  ones that contain Willy Tarreau's panic fix.

As for not putting new stuff in 2.4.x kernels, here is where we stand;
We believe new distributions based on 2.4.x kernels will keep showing 
for at least a year, probably longer, and that customers would like 
to see more bonding features in those distributions, so our intention 
is to keep getting new stuff into 2.4. We understand the drive to put 
new stuff into 2.6 and backport to 2.4 from time to time, but we'll 
really need to keep doing stuff the current way for a while.

The cleanup stuff came up as a necessity before developing the next 
set of features, and those are all based on a cleaned-up bonding, so 
delaying the acceptance of the cleanup into 2.4 also delays our 
features acceptance.

I'm waiting for the final word from everyone. I'll need to test the 
two new versions, but then I can release them accordingly.

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

[Chad N. Tindel]

> So here is what I did in the meantime:
> * Created a version for 2.4 that puts back all old compatibility stuff 
>   that was removed either during the propagation set or the cleanup 
>   set.
> * Created a version for 2.6 that puts back just the compatibility 
>   stuff that was removed in the propagation set (BOND_SETHWADDR, since 
>   we got a complaint from a RH9 user).
> * Removed the mention of the multicast param from the read-me.
> * Raised the ABI version to 2 so the new ifenslave keeps propagating 
>   IP settings to slaves for older drivers, and doesn't do that for new 
>   ones that contain Willy Tarreau's panic fix.

I like this.

Chad

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

[Jay Vosburgh]

>> So here is what I did in the meantime:
>> * Created a version for 2.4 that puts back all old compatibility stuff 
>>   that was removed either during the propagation set or the cleanup 
>>   set.
>> * Created a version for 2.6 that puts back just the compatibility 
>>   stuff that was removed in the propagation set (BOND_SETHWADDR, since 
>>   we got a complaint from a RH9 user).
>> * Removed the mention of the multicast param from the read-me.
>> * Raised the ABI version to 2 so the new ifenslave keeps propagating 
>>   IP settings to slaves for older drivers, and doesn't do that for new 
>>   ones that contain Willy Tarreau's panic fix.
>
>I like this.

	Same here, but I'd like to have a list somewhere of what each
of the ABI versions is for and how they're supposed to behave.  It's
starting to look like we're going to be adding these on a semi-regular
basis, so we need to keep track of what each one does and why.

	I also don't have any major heartburn about leaving the OLD
thingies in 2.4.  I'd like to remove them, but part of my reason for
wanting to nuke them was to keep 2.4 and 2.6 identical, but we're not
doing that, so it's not as big a concern.

	-J

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

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

[Shmulik Hen]

On Wednesday 01 October 2003 10:25 pm, Jay Vosburgh wrote:
> 	Same here, but I'd like to have a list somewhere of what each
> of the ABI versions is for and how they're supposed to behave. 
> It's starting to look like we're going to be adding these on a
> semi-regular basis, so we need to keep track of what each one does
> and why.
>

Where should such a list go ?
Currently, 0 or none is for doing everything the old way.
1 is for not setting slaves HW addr via ifenslave and leaving them in 
down state so the driver gets them with their unique address, sets 
them according to the mode and brings them up. The driver also 
restores the original address upon release. This is all done for 
supporting the 802.3ad, TLB, ALB modes.
2 will be for ifenslave lite that doesn't propagate the bond's IP 
settings to the slaves.
I'm guessing that 3 will be used to designate the new support for hot 
operations that Amir is working on.

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

>Where should such a list go ?

	Oh, I was thinking either in a comment block (by the ABI
version definitions, for example), tacked on to the end of
bonding.txt, or maybe in a README.ABI in the bonding/ directory.  I'm
not too concerned about where it is.  I just don't want to find
ourselves a year or two down the road trying to figure out just what
ABI version N is supposed to do when it suddenly quits working....

	-J

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

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

[Shmulik Hen]

I wrote:
> * Created a version for 2.4 that puts back all old compatibility 
>   stuff that was removed either during the propagation set or the 
>   cleanup set.
> * Created a version for 2.6 that puts back just the compatibility 
>   stuff that was removed in the propagation set (BOND_SETHWADDR, 
>   since we got a complaint from a RH9 user).

Jeff,

I'm going to need a ruling from you:

We understood from David that support of old ioctl definitions (i.e. 
those mapped to SIOCDEVPRIVATE) needs to be removed in the 2.6 
kernel. This will break compatibility with old versions of ifenslave 
(at least 2 years old, but still included in recent distributions 
like Red Hat 9).

If removing those private ioctls is a necessity for 2.6, then breaking 
compatibility with the old ifenslave versions is inevitable, so we 
might as well remove all compatibility stuff from the 2.6 bonding 
module (not just the private ioctls). Of course, we'll keep ifenslave 
fully compatible with all versions of bonding, so the user only needs 
to upgrade the tool once.

Given the above, how do you feel about removing old backward 
compatibility stuff from bonding in 2.6 ?

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