linux-kernel - Re: [-mm patch] one e1000 driver should be enough for everyone

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070725144615.GC3572@stusta.de>
Date:	Wed, 25 Jul 2007 16:46:16 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Auke Kok <auke-jan.h.kok@...el.com>,
	linux-kernel@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	netdev@...r.kernel.org
Subject: Re: [-mm patch] one e1000 driver should be enough for everyone

On Wed, Jul 25, 2007 at 09:48:55AM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> BTW:
>> Unless I'm misunderstanding anything, the new driver should support a 
>> superset of what the old driver supported.
>> Therefore, it would be good if the final merge into Linus' tree will
>> do an
>>   rm -r drivers/net/e1000
>>   mv drivers/net/e1000new drivers/net/e1000
>
> Based on the most recent discussion, e1000new (or whatever it will be 
> called) should support only the newer PCI-Express chips, while e1000 will 
> retain support for the older chips.

I found the discussion, and Christoph's e1000e sounds like the best name 
("new" doesn't say whether it's a new driver for old hardware or a 
driver for new hardware).

> Over the long term this will allow e1000new to grow without affecting 
> support for the older, stable chips.
>
> So, e1000 is not going away.

No problem for me, but this obviously implies that global code in the 
new driver has to be renamed.

And please ensure that they will always support distinct PCI IDs, or 
there will be the following common pattern if both drivers support
a card:
- user tries driver A
- driver A doesn't work (although it should have worked)
- user tries driver B
- driver B works
- a later kernel removes support for this card from driver B
- user tries driver A
- driver A still doesn't work
- user writes bug report

Users should report bugs early instead of bouncing between different 
drivers.

> 	Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/