[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46927259.4060403@intel.com>
Date: Mon, 09 Jul 2007 10:37:29 -0700
From: "Kok, Auke" <auke-jan.h.kok@...el.com>
To: Bill Davidsen <davidsen@....com>
CC: Adrian Bunk <bunk@...sta.de>, 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
Bill Davidsen wrote:
> Adrian Bunk wrote:
>> On Thu, Jul 05, 2007 at 12:01:56PM -0400, Bill Davidsen wrote:
>>
>>> Please do not make unnecessary kernel changes which require changes in our
>>> systems.
>
>>> If you think the e100 driver fixes your problems use it and be happy. But
>>> since you don't have to test system behavior with the new driver, and you
>>> won't be called at night or on weekends if it doesn't work, do the rest of
>>> the world a favor and stop taking out things we know to work! Leaving in
>>> the eepro100 causes no work for you, and even if e100 works perfectly it
>>> needs to be validated in any sane network. it still makes work.
>>>
>> The goal is to get e100 better, and removing eepro100 helps with
>> reaching this goal.
>>
> That's *your* goal, it should not be a shock that users have a goal of
> using their systems without having to reconfigure them every time
> there's a kernel upgrade containing a security fix.
unfortunately it is impossible for anyone to patch *every* old version of an OS
there is. Not only do we not want to do this (too much work, little return), but
most of the times it is exponentially more difficult to fix a security bug in an
older OS version than a new one.
>> 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.
>
> If there were any benefit to removing a working driver I would at least
> be able to see it as a resources issue, but as far as I can see you just
> seem to have a personal preference for the e100 driver and want to force
> others to use it because you are so much better able to decide what
> users need than the system administrators. That's one of the reasons
> people choose open source, because they have a choice, and can use
> what's best for them.
as discussed before we really want to avoid having (1) an unmaintained
bitrotting driver for X and (2) one that should work because people are being
paid to take care of it.
The community has always encouraged us to work with us fixing the last issues in
e100 to make it work for everyone. After all, we have all the documentation and
facilities here to do almost all of the work.
I asked Adrian to postpone removing the eepro100 driver since we know that e100
is still not working on some platforms. However, if e100 is not working on your
specific platform, then I would certainly like to know about your problem, and
whether it still exists. This is orthogonal to your argument: Your complaint
stands (and eepro100 will not be removed until we address the ARM platform
issues), but I ask you kindly to work with us and test the current e100 driver
and report any issues to us.
Cheers,
Auke
-
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