Re: Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

Re: Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

[Shmulik Hen]

On Monday 20 October 2003 06:42 pm, Jay Vosburgh wrote:
>
> >I disagree. I think that the latest version of ifenslave should
> > work with all versions of the bonding module that we can
> > reasonably expect people to use. This means that if ifenslave
> > fails to use the new interface it can try the old one. (This is
> > how I understood Jeff's position).
>
>         When we discussed this previously, my understanding was:
>
>         An ifenslave only had to work forwards, it didn't need to
> go backwards.  So, an ifenslave from 2.4.X would run on that
> version, as well as any future 2.4.Y (where Y > X).  But, the
> reverse isn't true: ifenslave from 2.4.Y need not work on kernel
> 2.4.X (again, Y > X).

Suppose a user updates an application package (in this case iputils). 
It seems unreasonable to require a kernel upgrade to make the updated 
app work.

Likewise, if the user updates the kernel, existing apps should still 
work. The sole exception is when switching major kernel versions (and 
even this should be avoided where possible). This is similar to the 
modutils package that has to be updated to work with 2.6. (and once 
updated it works with 2.4 as well).

This is how we've understood Jeff's approach when the ABI issue was 
first raised:
[From <http://sourceforge.net/mailarchive/message.php?msg_id=4875256>]
    On 12 May 2003, Jeff Garzik wrote:
    > FWIW the main worry is users booting into "new bonding" and "old
    > bonding" kernels, with the same userspace.  (which of course
    > implies an ifenslave userspace upgrade, but that's ok)


Based on the above assumptions, and on the fact that removing 
SIOCDEVPRIVATE support from bonding in 2.6 already breaks 
compatibility with existing ifenslave apps, we thought the sensible 
thing to do would be to drop all support of old interfaces from 
bonding in 2.6 (including the current SIOCBOND* ioctls), and thus 
force users that upgrade to 2.6 to use a new ifenslave (that can be 
found either in the 2.6 kernel tree or at sourceforge). This new 
ifenslave will also support any 2.4 bonding.

After a while, we will probably backport the new interface into the 
2.4 bonding module, so it too will benefit from the its new 
capabilities.

>         Applying this to 2.6, a 2.6 ifenslave shouldn't need to
> control a 2.4 bonding driver, but a 2.4 ifenslave should control a
> 2.6 kernel (for reasonable ranges of 2.4.X, in particular excluding
> SIOCDEVPRIVATE).
>
>         I was thinking that the 2.4 ifenslave should work with 2.4
> or 2.6 (including the new shiny API, to make kernel upgrades less
> hassle), but the 2.6 ifenslave need not work with 2.4, so we could
> hopefully vacuum it clean of the various ABI gook once we have a
> new shiny interface.  The 2.6 ifenslave presumably won't be
> included in a distro until they ship a 2.6 kernel, so that would
> theoretically be sufficient.

The thing to note here is that there is no "2.6 ifenslave" and "2.4 
ifenslave" per se. The ifenslave app lives in several places: the 
kernel source tree, the bonding sourceforge site, the iputils RPM, 
etc. The important thing is that updating this app should not require 
a kernel upgrade.

> >We can probably provide a version of bonding/ifenslave that works
> > with the new interface within two weeks (hopefully less). This
> > is, of course, assuming we reach a consensus on the compatibility
> > issue.
>
>         Would that be dependant upon the cleanup stuff, or not?

Yes, it will. We do all our code developement on top of the cleanup 
stuff.

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

Re: Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

[Jay Vosburgh]

[...]
>Based on the above assumptions, and on the fact that removing 
>SIOCDEVPRIVATE support from bonding in 2.6 already breaks 
>compatibility with existing ifenslave apps, we thought the sensible 
>thing to do would be to drop all support of old interfaces from 
>bonding in 2.6 (including the current SIOCBOND* ioctls), and thus 
>force users that upgrade to 2.6 to use a new ifenslave (that can be 
>found either in the 2.6 kernel tree or at sourceforge). This new 
>ifenslave will also support any 2.4 bonding.
>
>After a while, we will probably backport the new interface into the 
>2.4 bonding module, so it too will benefit from the its new 
>capabilities.

	I was leaning towards supporting existing 2.4 ifenslaves (not
the ancient ones using SIOCDEVPRIVATE, but more recent versions) so
that end users could hypothetically dabble with the 2.6 bonding
without messing with their 2.4 user space.  In that way, the 2.6 (or
"new ifenslave," if you prefer) ifenslave wouldn't have all of the old
2.4-style bonding API stuff in it.

	Anyway, I can live with the above; it does require an
ifenslave upgrade to dabble with 2.6, but as long as the 2.4
reliability isn't affected, I don't see a problem with it.

[...]
>The thing to note here is that there is no "2.6 ifenslave" and "2.4 
>ifenslave" per se. The ifenslave app lives in several places: the 
>kernel source tree, the bonding sourceforge site, the iputils RPM, 
>etc. The important thing is that updating this app should not require 
>a kernel upgrade.

	I'm having a thought here... Would it be both feasible and
reasonable to pull ifenslave.c out of the kernel source, and maintain
a separate bonding-utils package, wherein the shiny new API has some
knowledge of ifenslave versions?  In this way, the bonding kernel
driver could enforce version requirements for ifenslave, possibly at a
per-feature granularity (e.g., "need ifenslave version X for
frog-blending mode").  In this way, we'd have just one ifenslave
development line (not two), and somewhat better upgrade prospects over
time.

	In the past, I'd thought this (a bonding-utils package for
ifenslave) wasn't an especially good idea, because I didn't really see
much advantage for us in doing it.  Now, it looks like it is to our
advantage to have just one ifenslave development line, distinct from
the kernel development line (if the single ifenslave will be going
both ways there's no reason to keep two separate copies in the 2.4 and
2.6 kernel trees).

	I really do like having ifenslave right there in the kernel
source, it's very handy, but it may be better overall to pull it out
and distribute it separately.

	Comments?  Chad, you out there?  I know you really like having
ifenslave in the kernel source; what do you think about this?

	-J

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

Re: [Bonding-devel] Re: Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

[Chad N. Tindel]

> 	In the past, I'd thought this (a bonding-utils package for
> ifenslave) wasn't an especially good idea, because I didn't really see
> much advantage for us in doing it.  Now, it looks like it is to our
> advantage to have just one ifenslave development line, distinct from
> the kernel development line (if the single ifenslave will be going
> both ways there's no reason to keep two separate copies in the 2.4 and
> 2.6 kernel trees).
> 
> 	I really do like having ifenslave right there in the kernel
> source, it's very handy, but it may be better overall to pull it out
> and distribute it separately.
> 
> 	Comments?  Chad, you out there?  I know you really like having
> ifenslave in the kernel source; what do you think about this?

I have had many numerous users email me specifically to say that they like
to have the ifenslave.c in the kernel.  They know that no matter what, when
they upgrade their kernel, they can simply compile the ifenslave that is there
and it will work.  They don't want to have to go hunt around on some website
to try to find a working ifenslave. 

In contrast, I have seen nothing but pain when trying to separate userspace
from kernel space.  Trying to get the right iputils package to match up
with the kernel you are using is a pain; and it makes the iputils stuff
just that much harder to maintain, for the same reasons we're discussing.

I have never heard of anyone complaining that ifenslave.c is packaged
with the kernel source.  

Chad

Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

[Noam, Amir]

[adding netdev to the discussion]

"Chad N. Tindel" <chad@tindel.net> wrote:

>  > >I say that if people want to switch between 2.4 and 2.6, they can
>  > >write a script to create the appropriate ifenslave symbolic link.
>  > 
>  > 	To clarify, I'm interpreting this to mean:
>  > 
>  > 	2.4.X ifenslave (where "X" is recent enough that it doesn't
>  > use SIOCDEVPRIVATE) should work with 2.6.anything.

I disagree. See below.

>  > 	2.4.X ifenslave (where "X" is old and it uses SIOCDEVPRIVATE)
>  > need not work with 2.6.anything.
>  > 
>  > 	2.6.X ifenslave (where "X" is 0 or better) should work with
>  > any 2.6 later than the one it was shipped with.

Yes.

>  > 	2.6.X ifenslave (where "X" is 0 or better) need not work with
>  > 2.4.anything.

I disagree. I think that the latest version of ifenslave should work
with all versions of the bonding module that we can reasonably expect
people to use. This means that if ifenslave fails to use the new
interface it can try the old one. (This is how I understood Jeff's
position).

However, I'm definitely in favor of dropping compatibility in the
*module* in 2.6. This is because most recent distributions (Red Hat 9,
for example) still use an antique version of ifenslave that still uses
the SIOCDEVPRIVATE ioctls. If we remove support for these ioctls in
2.6 (as we should), then the bonding module will break compatibility
with those ifenslave versions anyway. I see no point in trying to keep
compatibility with the ifenslave version that is in the 2.4 kernel
tree, while it is not yet in use by any distribution.

>  My opinion is this.  What has worked in 2.4 in the past 
>  should always work
>  for 2.4.  Once you upgrade to 2.6, all bets for that are off.  

I agree, except that I think that if you upgrade to 2.6, and update
your ifenslave accordingly, you shouldn't have to switch user space
utilities when you boot into different kernels. That's why I said that
once you update ifenslave it should work with old bonding as well.

>  > 	Amir, how close are you to having a first draft patch for
>  > inspection?  I'm not concerned so much that it be fully baked
>  > as that
>  > it be something to look at and mess with for the usual gang.

We can probably provide a version of bonding/ifenslave that works with
the new interface within two weeks (hopefully less). This is, of course,
assuming we reach a consensus on the compatibility issue.

>  > 	Am I nuts to want to get the new API stuff in for 2.6.0?  It'd
>  > be nice to not be locked in to supporting the current 
>  scheme because
>  > the first ifenslave in 2.6.0 uses it.
>  
>  I agree wholeheartedly.

I also agree. The question is, can we really push such a change into
bonding in 2.6, now that Linus only accepts bug fixes?

Amir

Re: Changing bonding <-> ifenslave interface [was: Problem with current /proc entries]

[Jay Vosburgh]

	The "To clarify, I'm interpreting" comments are mine (3 ">");
Chad's are one up and down (2 and 4 ">").

>"Chad N. Tindel" <chad@tindel.net> wrote:
>
>>  > >I say that if people want to switch between 2.4 and 2.6, they can
>>  > >write a script to create the appropriate ifenslave symbolic link.
>>  > 
>>  > 	To clarify, I'm interpreting this to mean:
>>  > 
>>  > 	2.4.X ifenslave (where "X" is recent enough that it doesn't
>>  > use SIOCDEVPRIVATE) should work with 2.6.anything.
>
>I disagree. See below.
>
>>  > 	2.4.X ifenslave (where "X" is old and it uses SIOCDEVPRIVATE)
>>  > need not work with 2.6.anything.
>>  > 
>>  > 	2.6.X ifenslave (where "X" is 0 or better) should work with
>>  > any 2.6 later than the one it was shipped with.
>
>Yes.
>
>>  > 	2.6.X ifenslave (where "X" is 0 or better) need not work with
>>  > 2.4.anything.
>
>I disagree. I think that the latest version of ifenslave should work
>with all versions of the bonding module that we can reasonably expect
>people to use. This means that if ifenslave fails to use the new
>interface it can try the old one. (This is how I understood Jeff's
>position).

	When we discussed this previously, my understanding was:

	An ifenslave only had to work forwards, it didn't need to go
backwards.  So, an ifenslave from 2.4.X would run on that version, as
well as any future 2.4.Y (where Y > X).  But, the reverse isn't true:
ifenslave from 2.4.Y need not work on kernel 2.4.X (again, Y > X).

	Applying this to 2.6, a 2.6 ifenslave shouldn't need to
control a 2.4 bonding driver, but a 2.4 ifenslave should control a 2.6
kernel (for reasonable ranges of 2.4.X, in particular excluding
SIOCDEVPRIVATE).

	I was thinking that the 2.4 ifenslave should work with 2.4 or
2.6 (including the new shiny API, to make kernel upgrades less
hassle), but the 2.6 ifenslave need not work with 2.4, so we could
hopefully vacuum it clean of the various ABI gook once we have a new
shiny interface.  The 2.6 ifenslave presumably won't be included in a
distro until they ship a 2.6 kernel, so that would theoretically be
sufficient.

>However, I'm definitely in favor of dropping compatibility in the
>*module* in 2.6. This is because most recent distributions (Red Hat 9,
>for example) still use an antique version of ifenslave that still uses
>the SIOCDEVPRIVATE ioctls. If we remove support for these ioctls in
>2.6 (as we should), then the bonding module will break compatibility
>with those ifenslave versions anyway. I see no point in trying to keep
>compatibility with the ifenslave version that is in the 2.4 kernel
>tree, while it is not yet in use by any distribution.

	When you say "dropping compatibility" are you just referring
to the SIOCDEVPRIVATE ioctls, or the full "old style" ifenslave to
bonding API (which would be replaced by the new shiny interface you
were talking about earlier)?

>>  My opinion is this.  What has worked in 2.4 in the past 
>>  should always work
>>  for 2.4.  Once you upgrade to 2.6, all bets for that are off.  
>
>I agree, except that I think that if you upgrade to 2.6, and update
>your ifenslave accordingly, you shouldn't have to switch user space
>utilities when you boot into different kernels. That's why I said that
>once you update ifenslave it should work with old bonding as well.

	As I said above, I don't think we need to put ourselves in the
position of supporting both backwards compatibility (old ifenslave,
new bonding) and forwards compatibility (new ifenslave, old bonding).

	I'm thinking we should give the 2.4 ifenslave the "shiny new
API" stuff (which is only applicable to the 2.6 bonding driver) so
that it'll run with 2.6 for the forseeable future, and then excise the
existing API from 2.6 (realistically, at some point in the future,
probably when 2.6 becomes "the standard").

	Comments?

>We can probably provide a version of bonding/ifenslave that works with
>the new interface within two weeks (hopefully less). This is, of course,
>assuming we reach a consensus on the compatibility issue.

	Would that be dependant upon the cleanup stuff, or not?

>>  > 	Am I nuts to want to get the new API stuff in for 2.6.0?  It'd
>>  > be nice to not be locked in to supporting the current 
>>  scheme because
>>  > the first ifenslave in 2.6.0 uses it.
>>  
>>  I agree wholeheartedly.
>
>I also agree. The question is, can we really push such a change into
>bonding in 2.6, now that Linus only accepts bug fixes?

	That I don't know.  Most of this is moot if we can't mess with
2.6.

	-J

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