[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46928EB3.9020506@tmr.com>
Date: Mon, 09 Jul 2007 15:38:27 -0400
From: Bill Davidsen <davidsen@....com>
To: Adrian Bunk <bunk@...sta.de>
CC: "Kok, Auke" <auke-jan.h.kok@...el.com>, jgarzik@...ox.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
saw@....sw.com.sg, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [2.6 patch] the overdue eepro100 removal
Adrian Bunk wrote:
> On Mon, Jul 09, 2007 at 01:27:55PM -0400, Bill Davidsen wrote:
> For how many years do you know that there's a new and actively
> maintained e100 driver for your hardware?
>
> And if you don't follow a stable line like the 2.6.16 kernel or a
> distribution kernel it's simply a part of the current development model
> that some kernel parts change. If changing one driver results in a big
> problem in your setup you should reconsider your setup. And every new
> kernel except for -stable kernels will anyway require a revalidation, so
> changing the network driver as part of this shouldn't be a big issue.
>
Nothing is a "big issue" if you can force someone else to do the work.
And if you have no impact from a production outage if some new driver
works for hours and then does something unexpected.
>>> Why didn't _you_ try the e100 driver when you validated your systems after
>>> you upgraded them to kernel 2.6, and if you did and it didn't work, where
>>> is your bug report?
>>>
>> Is that a joke, or subtle irony? Do you generally validate drivers you
>> don't use just because your hardware might be able to support them? I don't
>> validate various accelerated video drivers on systems running mostly text
>> console, never check sound options on systems with an audio application,
>> etc. After I tried the e100 driver on the first few systems and found
>> issues (which may be resolved by now) I went back to eepro100 and used what
>> worked. And used the driver for any new systems in other installs.
>
> And exactly this is the reason why the eepro100 driver has to be
> removed, and that this will result in a better hardware support for
> everyone in the long term.
>
If this was a case of a kernel change requiring an effort to keep the
driver I would not be suggesting someone take time to update the driver
from threads to tasklets or fartlets or whatever the next ultimate irq
handling happens to be. But when there's zero effort at the moment to
retain the driver, I think it's change for the sake of change.
--
Bill Davidsen <davidsen@....com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists