From: "Chad N. Tindel" <chad@tindel.net>
To: netdev@oss.sgi.com
Subject: Re: [bonding] compatibilty issues
Date: Mon, 29 Sep 2003 19:25:34 -0400 [thread overview]
Message-ID: <20030929232534.GB93323@calma.pair.com> (raw)
[-- 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
next reply other threads:[~2003-09-29 23:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 23:25 Chad N. Tindel [this message]
2003-09-29 23:38 ` [bonding] compatibilty issues Jeff Garzik
2003-09-30 0:23 ` Chad N. Tindel
2003-09-30 5:54 ` David S. Miller
[not found] <E791C176A6139242A988ABA8B3D9B38A02A464F1@hasmsx403.iil.intel.com>
2003-09-30 11:42 ` Shmulik Hen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030929232534.GB93323@calma.pair.com \
--to=chad@tindel.net \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).