[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46928E54.9020607@linux.intel.com>
Date: Mon, 09 Jul 2007 12:36:52 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Jeff Garzik <jeff@...zik.org>
CC: "Kok, Auke" <auke-jan.h.kok@...el.com>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
Francois Romieu <romieu@...zoreil.com>,
Christoph Hellwig <hch@...radead.org>,
Andrew Grover <andy.grover@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
"Ronciak, John" <john.ronciak@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Andy Gospodarek <andy@...yhouse.net>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
?)
Jeff Garzik wrote:
<I'll leave the first two to Auke; the discussion I had with Auke on
Friday was that he felt that a lot of the "ugly" stuff you complained
about will go away if there is a PCI-E/older split, the PCI-E cards
are more or less of the same "major generation", while pre-PCI-E is
different>
> 3) Looming over everything else, is I wonder if Intel has recognized
> that a maintainership problem exists: lack of ongoing cleanups and lack
> of "focus" on issues not directly related to enabling new features?
>
> My only "bias" against Intel is that I am -nervous- that past history
> will continue, with regards to the "stuff it into the driver and move
> on" driver maintenance regime. Even most clean driver in the world will
> fall upon hard times if under-maintained.
We (the Intel people on this mail and various others inside Intel)
have been working hard to fix this issue several levels of management
up in the networking group and I am confident we have all the buy-in
to do the right thing now, and Auke has the time to do this. This was
quite an effort at Intel-internal politics, and that's obviously
something you don't (want to) care about or should have to care
about.... but the end result is that finally in the last month or two
things changed enough that I feel that the maintenance issue can be
done right. The flipside sort of is that there needs to be a chance to
prove this ;)
(and if you feel that it's not working please contact me so that I can
re-escalate things; I'll also be monitoring how things go)
> Receiving feedback, disappearing for months, and then reappearing with
> "blessed" changes is not adequate. netdev@...r.kernel.org and
> netdev-2.6.git need to be the primary vehicle for e1000[new]
> development, maintained through small incremental changes streaming into
> the kernel. (though I do understand the constraints of hardware
> go-public release dates)
Actually the biggest constraint for new hardware support is having
working prototypes ;-)
The market is such that there may be only a short time between having
a working prototype and a launch. (Before that there are design specs
of course, but reality is that unless you can do basic unit testing
shipping code for such new things is not a good thing, the chance of
things "just working" is obviously pretty low).
-
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