linux-kernel - Re: [patch] e1000=y && e1000e=m regression fix

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: <20080410144409.6a1da266.rdunlap@xenotime.net>
Date:	Thu, 10 Apr 2008 14:44:09 -0700
From:	Randy Dunlap <rdunlap@...otime.net>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Jeff Garzik <jeff@...zik.org>,
	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>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

On Thu, 10 Apr 2008 14:23:50 -0700 Kok, Auke wrote:

> Ingo Molnar wrote:
> > * Kok, Auke <auke-jan.h.kok@...el.com> wrote:
> > 
> >>>>  config E1000E_ENABLED
> >>>> -	def_bool E1000E != n
> >>>> +	def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
> >>> Uh, that's /not/ what Ingo's patch does.  His patch makes e1000 
> >>> claim the e1000e IDs if e1000 is built-in and e1000e is a module.
> >> so that's definately _not_ what I would like to see at all. Matthew 
> >> points out that this will just prolong users to use e1000 instead of 
> >> e1000e (which is what they should be encouraged to switch to in those 
> >> cases).
> >>
> >> so I'm dropping my ACK
> > 
> > why you want to cripple an existing, rather well working and popular 
> > Linux driver is beyond me.
> 
> Because we decided a long time ago to do this driver split. And everyone at that
> time agreed with that, and we set out to do this. And part of that plan was to
> move (not copy) the device IDs over.
> 
> We accepted that that might break some kernel developers' systems in the process
> and consulted several vendors and distros if they were OK with the change and they
> all agreed with the plan.
> 
> I do not want people with PCI Express e1000 cards to use e1000 for any day longer
> than is strictly needed, and I certainly do not want to prolong the period where
> both drivers could work on their adapters. That will be a far bigger nightmare for
> me than just a few kernel developers having a bad day.
> 
> I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
> you guys :)
> 
> Users will outnumber us kernel developers in complaints if we keep the situation
> unclear to them, and we already told them that they need to switch to e1000e for
> their PCI Express devices. If we now do stuff like what you proposed in that
> patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
> distro's start picking random device IDs or worse. Stuff like that is already
> happening, and discussions like these just add to the confusion.
> 
> Again - If there is a way to auto-enable e1000e in the right way so that more
> systems migrate better then I'm all for it (even if forcing E1000E=y). But it
> seems that the various patches proposed don't cut it and frankly Kconfig is
> completely inadequate as a hardware enabling script since it knows absolutely
> nothing about the hardware in the first place. And it wasn't meant for that
> either. `make oldconfig` is not the answer ;).

It would make much more sense IMO to add
CONFIG_E1000E=y
to defconfig ... and also to change
CONFIG_FUSION=y
to
CONFIG_FUSION=n
while there  :)

> Again - this has happened before, I remember many of my boxes not booting because
> SATA Kconfig options changed and all my boxes failed to move the proper Kconfig
> symbols over when I ran `make oldconfig` myself. Somewhere around 2.6.20 or so.


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