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

["Chad N. Tindel" <chad@tindel.net>]

> 	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