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: <47FFF7B5.3000609@garzik.org>
Date:	Fri, 11 Apr 2008 19:43:49 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Daniel Barkalow <barkalow@...ervon.org>,
	Christoph Hellwig <hch@...radead.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Ingo Molnar <mingo@...e.hu>, Matthew Wilcox <matthew@....cx>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>,
	e1000-list <e1000-devel@...ts.sourceforge.net>,
	linux-pci maillist <linux-pci@...ey.karlin.mff.cuni.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	Greg KH <greg@...ah.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [patch] e1000=y && e1000e=m regression fix

Linus Torvalds wrote:
> .. but that said, I think your patch is certainly better than what we have 
> now (or what Ingo was complaining about for the next merge window). I 
> certainly could live with it. I would just suggest against ever then 
> removing that "generic E1000" choice.


You mean never ever remove PCI-E support from e1000?

Won't that will inflict long term headaches on the people that matter 
most -- users and maintainers -- to avoid short term headaches for 
kernel power users?

To review the overall situation,

* e1000 supports so many chips, that making a change for new hardware in 
e1000 involves breaking stability of older chips

* //You know this// from past kernel history, when late-breaking e1000 
changes for new hardware wound up breaking working setups on multiple 
occasions

* There is 100% agreement that e1000 is a maintenance nightmare, from 
the people who actually touch the code (or even read it).

* Therefore, e1000e receives new h/w support and new devel, leaving 
e1000 to sit and be stable


However, due to a mistake now released to the public -- a tiny few PCI-E 
chips are supported by e1000 -- you have a widely disparate feature set:

	e1000, old chips:		full support

	e1000, a few PCI-E chips:	basic support

	e1000e, all PCI-E chips:	full support

Since e1000e is all new and fancy AND CLEAN, the code for the same chips 
is different -- thus Intel must make every PCI-E fix _twice_.

It also means WE HAVE TO KEEP TOUCHING E1000, while supporting PCI-E 
chips.  After this PCI-E issue is resolved, I want to let e1000 sit and 
be stable and not be touched.

For a temporary situation, this is fine.  Give me transition 
suggestions, please!

For a permanent situation, that sucks.

Distros will ship e1000 sans PCI-E support, which means you are asking 
that PCI-E support be maintained indefinitely, purely for the few kernel 
hackers that still use it?

I __don't care__ how we get there, but a permanent situation where e1000 
continues to support a few PCI-E chips in basic mode seems the least 
desireable of all available options.

Wait six months?  Sure.  Whatever.  As long as we get to where we can 
disable PCI-E support in e1000.

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ