From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Adrian Bunk <bunk@stusta.de>,
jgarzik@pobox.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, saw@saw.sw.com.sg,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [2.6 patch] the overdue eepro100 removal
Date: Mon, 09 Jul 2007 10:37:29 -0700 [thread overview]
Message-ID: <46927259.4060403@intel.com> (raw)
In-Reply-To: <4692701B.3030506@tmr.com>
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
next prev parent reply other threads:[~2007-07-09 17:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-01 20:21 [2.6 patch] the overdue eepro100 removal Adrian Bunk
2007-07-01 20:33 ` Kok, Auke
2007-07-01 21:51 ` Jeff Garzik
2007-07-02 19:02 ` Bill Davidsen
2007-07-02 21:45 ` Kok, Auke
2007-07-05 16:01 ` Bill Davidsen
2007-07-09 12:52 ` Adrian Bunk
2007-07-09 17:27 ` Bill Davidsen
2007-07-09 17:37 ` Kok, Auke [this message]
2007-07-09 17:53 ` Jeff Garzik
2007-07-09 17:52 ` Adrian Bunk
2007-07-09 19:38 ` Bill Davidsen
2007-07-09 20:43 ` Ian McDonald
-- strict thread matches above, loose matches on Subject: below --
2008-05-19 21:53 Adrian Bunk
2008-08-06 21:10 Adrian Bunk
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=46927259.4060403@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=bunk@stusta.de \
--cc=davidsen@tmr.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=saw@saw.sw.com.sg \
--cc=torvalds@linux-foundation.org \
/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).