mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: shmulik.hen@intel.com
Cc: "Chad N. Tindel" <chad@tindel.net>,
	bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com,
	linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
	Jeff Garzik <jgarzik@pobox.com>,
	"Noam, Amir" <amir.noam@intel.com>,
	"Mendelson, Tsippy" <tsippy.mendelson@intel.com>,
	"Noam, Marom" <noam.marom@intel.com>
Subject: Re: [Bonding-announce] [PATCH SET][bonding] cleanup
Date: Thu, 25 Sep 2003 10:33:31 -0700	[thread overview]
Message-ID: <200309251733.h8PHXWpV013559@death.ibm.com> (raw)
In-Reply-To: Message from Shmulik Hen <shmulik.hen@intel.com>  of "Thu, 25 Sep 2003 20:11:53 +0300." <200309252011.53960.shmulik.hen@intel.com>


	[removed bonding-announce from cc:]

>On Thursday 25 September 2003 07:47 pm, Chad N. Tindel wrote:
>> > patch 4 - remove dead code, old compatibility stuff and redundant
>> >           checks.
>>
>> I'm a bit concerned about doing some of this stuff in the 2.4
>> series.  That compatibility stuff is there for a reason, and was
>> set to be removed in 2.6.  Perhaps we shouldn't be doing stuff this
>> drastic until 2.6 because of the risk of breaking users.
>
>That's the word I got from Jay in response to the " [Kernel-janitors] 
>old ioctl definitions in 2.5" thread.
>
>>Jay Vosburgh <fubar@us.ibm.com> wrote:
>>	I was going to add it on to the end of the clean up set, but
>> if you want to do it, go ahead.  Nobody seems to have objected to
>> removing the _OLD stuff, which I view as a good thing.

	My thinking here is that any ifenslave old enough (two years
or more) to still be using the OLD ioctl values is unlikely to work
with the current kernel driver, and if somebody did try it, it's
better to have the call fail outright than perform weird and
mysterious rituals in kernel memory.  I have trouble envisioning an
scenario where a user would be using the latest 2.4.23 kernel, but an
ifenslave from, what, 2.2.15? 2.4.5? or so.

	Separately, recent ifenslaves have compatibility code within
them to cover the great "ifenslave calling sequence change" from April
or so.  As much as I love the sleek new slimmed down ifenslave, I'm
not absolutely sure we can nuke that compatibility stuff within
ifenslave.  I really, really wanna, but I'm not sure if it will cause
problems for end users.  This is the upgrade scenario that prompted
the creation of the whole "ABI version" and compat stuff in the first
place; if we don't have to worry about that, then the simpler
ifenslave can be used, and I think the ethtool ABI version hack can go
away (since we wouldn't need an ABI version if there's only one).

	Comments?

	-J

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

  reply	other threads:[~2003-09-25 17:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-25 12:49 Shmulik Hen
2003-09-25 16:22 ` Jay Vosburgh
2003-09-25 16:47 ` [Bonding-announce] " Chad N. Tindel
2003-09-25 17:11   ` Shmulik Hen
2003-09-25 17:33     ` Jay Vosburgh [this message]
2003-09-25 17:43       ` Shmulik Hen
2003-09-25 21:13       ` Chad N. Tindel
2003-10-05 22:28         ` Willy TARREAU

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=200309251733.h8PHXWpV013559@death.ibm.com \
    --to=fubar@us.ibm.com \
    --cc=amir.noam@intel.com \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=chad@tindel.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=noam.marom@intel.com \
    --cc=shmulik.hen@intel.com \
    --cc=tsippy.mendelson@intel.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

all inboxes | Powered by JetHome®