[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 <[email protected]> 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, [email protected]
On Thursday 25 September 2003 08:33 pm, Jay Vosburgh wrote:
>
> 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?
>
I think I better leave this for Amir to answer. He's our ABI expert
and this needs carefull consideration, especially now that he's
working on enhancing ifenslave's capabilities for the hot operation
stuff. However, he won't be able to do that before Monday since we're
going out on a long weekend - it's holiday season over here.
--
| Shmulik Hen Advanced Network Services |
| Israel Design Center, Jerusalem |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp. |
> >> 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.
I was specifically told by David Miller that we are not to break binary
compatibility within a 2.4 release. Such things had to wait until 2.5
or later. We can not require a user to upgrade their ifenslave within a 2.4
series kernel just to keep using the same functionality they were using in
2.4.1. Obviously we can require them to upgrade in order to keep using
new functionality. So the _OLD stuff needs to stay in the 2.4 kernel. If
this was brought up in an earlier thread, then I just missed it.
Chad