netdev - Re: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <46899408.4030407@hp.com>
Date:	Mon, 02 Jul 2007 17:10:48 -0700
From:	Rick Jones <rick.jones2@...com>
To:	"Williams, Mitch A" <mitch.a.williams@...el.com>
Cc:	Mark McLoughlin <markmc@...hat.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	Jason Lunz <lunz@...lexsecurity.com>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

> There seems to be a lot of concern over obsoleting the e1000 driver
> too quickly, and with confusing users (and startup scripts) about which
> driver to load.

Yes.

> Obviously, we at Intel want to get e1000new into the kernel as quickly
> as possible, and to obsolete e1000 also as quickly as possible.  The
> point of this exercise is to reduce our support and maintenance burden,
> and e1000new has shown itself internally to be much easier to work on.
> 
> So how about this:
> - We include e1000new in 2.6.23, along side e1000.  We expose ICH9
>   device IDs in e1000new, and gate the rest of the IDs inside
>   #ifndef CONFIG_E1000.  This gives distis ICH9 support, along
>   with a guarantee of the known e1000 driver.  It also lets the more
>   bleeding-edge people turn off e1000 and run with just e1000new to
>   work out any kinks.
> - For 2.6.24, we reverse the situation:  Gate all device IDs in e1000
>   behind #ifndef CONFIG_E1000NEW, and expose all of them in e1000new.
>   At this point we (i.e. the community, not just Intel) should be 
>   confident in e1000new, and we can mark e1000 as obsolete.  It's still
>   a fallback option for those with old/funky/misconfigured hardware.
> - After a year (or whatever), we remove e1000.
> 
> Seems to me that this plan should appease either everybody or nobody.
> We get ICH9 support out there, e1000new gets in the kernel and
> exercised, and we get to set a definite date for obsoleting e1000.

What sort of timeframes are we looking at with 2.6.23 and then 2.6.24 
and how might they map to distro releases?  Much as everyone 
wants/encourages folks to test the kernel.org kernels and such, the 
_real_ exposure still seems to come with a distro release.

Rambling a bit, and recognizing that "e1000new" was probably just a 
strawman name, but I suspect that a _very_ different name for the new 
driver would be a good thing, rather than a varition on the e1000 theme. 
  "The Law of the Telephone Game" pretty much guaratees that something 
with "e1000" in its name will be shortened to just "e1000."

How about "elk" (ee el kay) - applying that same "telephone" game 
(consistency? nah) to e1000 to get e1k, which if you look at it quickly 
enough looks like elk.  OK, that's half in jest, but only half.  I may 
be wrong, but I don't think I've seen anyone shortening the current 
e1000 to e1k?

rick jones
-
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