Jeff Garzik wrote:
Kok, Auke wrote:
Sorry for not replying to this earlier (I was on vacation for 2 days).
We had some internal discussions and all the noses appear to be facing
in the proper direction. I'm very happy with this and it will be my
highest priority to make this work. I will attem
Kok, Auke wrote:
Sorry for not replying to this earlier (I was on vacation for 2 days).
We had some internal discussions and all the noses appear to be facing
in the proper direction. I'm very happy with this and it will be my
highest priority to make this work. I will attempt to get a quick st
Jeff Garzik wrote:
Kok, Auke wrote:
I would strongly vote for taking a stripped down e1000new then, mask out
all the pci id's except ich9, remove all code for pre-pci-e silicon and
remove the most annoying and needlessly complexing code like the
semi-implemented multiqueue code that is in ther
Kok, Auke wrote:
I would strongly vote for taking a stripped down e1000new then, mask out
all the pci id's except ich9, remove all code for pre-pci-e silicon and
remove the most annoying and needlessly complexing code like the
semi-implemented multiqueue code that is in there.
I'm fine for th
Jeff Garzik wrote:
Ignoring small potatoes, the merge stoppers in my mind are:
1) Transition plan. I strongly oppose switching all e1000 users en
masse to a new driver, especially so soon. Flag day transitions to
unproven drivers suck. Defaults don't work: users use the old driver
until t
Jeff Garzik wrote:
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 ha
Let me ask a different question. Why do we have some many user reported
problems with network drivers, not just the E1000's?
Is it lack of specifications? test infrastructure?
Or as I suspect lots of it has to with the myriad of chip revisions, including
cases where designs get reworked by OEM's.
Arjan van de Ven wrote:
Jeff Garzik wrote:
Is this is the attitude, what's the point of even posting the driver
for review? Intel posted e1000new on June 29. Feedback was then posted.
and feedback is being incorperated.
Ten days later, without a single revision, Intel declares its own
dri
Andrew Grover wrote:
On 7/8/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
* e1000 gets feedback
* Intel disappears for months
* Intel reappears with e1000 rewrite
* you ask them for another complete (simpler) rewrite
* Intel fights tooth and nail when the driver is not accepted verboten
I don
Jeff Garzik wrote:
Arjan van de Ven wrote:
I'd second this; also lets be honest and fair about things and use a
similar standard for all drivers; are we going to ask all driver
submitters to remove NAPI, TSO and other stuff? I would hope not. Are
That was merely a suggestion. My general mea
On 7/8/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
* e1000 gets feedback
* Intel disappears for months
* Intel reappears with e1000 rewrite
* you ask them for another complete (simpler) rewrite
* Intel fights tooth and nail when the driver is not accepted verboten
I don't think it must be as
Stephen Hemminger wrote:
I think rather than having a meta-discussion, which always seems to degenerate
into finger pointing. Let's look at the code. The problem with popular drivers
(as I too well know) is that user's seem to find every wart. There are lots of
old drivers that never seem to get
Arjan van de Ven wrote:
I'd second this; also lets be honest and fair about things and use a
similar standard for all drivers; are we going to ask all driver
submitters to remove NAPI, TSO and other stuff? I would hope not. Are
That was merely a suggestion. My general meaning was "small driv
Kok, Auke wrote:
This is not acceptable and hardly fair to expect from us.
It also exposes users to endless delays and uncertainties as to a final
resolution. Not to mention that writing a driver from scratch for (just)
ich9 will take significant time, is silly since it's almost identical to
Stephen Hemminger wrote:
I would really like to continue with my original plan that I posted that follows
Christoph's idea. I hope you can all agree with that so we can get on with this.
I think rather than having a meta-discussion, which always seems to degenerate
into finger pointing. Let's l
Stephen Hemminger wrote:
I think rather than having a meta-discussion, which always seems to degenerate
into finger pointing. Let's look at the code. The problem with popular drivers
(as I too well know) is that user's seem to find every wart. There are lots of
old drivers that never seem to get
On Sat, 07 Jul 2007 14:54:11 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
> Francois Romieu wrote:
> > Kok, Auke <[EMAIL PROTECTED]> :
> >> Jeff Garzik wrote:
> >>> Kok, Auke wrote:
> > [...]
> >> This is not acceptable and hardly fair to expect from us.
> >>
> >> It also exposes users to endless
Francois Romieu wrote:
Kok, Auke <[EMAIL PROTECTED]> :
Jeff Garzik wrote:
Kok, Auke wrote:
[...]
This is not acceptable and hardly fair to expect from us.
It also exposes users to endless delays and uncertainties as to a final
resolution. Not to mention that writing a driver from scratch fo
Kok, Auke <[EMAIL PROTECTED]> :
> Jeff Garzik wrote:
> >Kok, Auke wrote:
[...]
> This is not acceptable and hardly fair to expect from us.
>
> It also exposes users to endless delays and uncertainties as to a final
> resolution. Not to mention that writing a driver from scratch for (just)
> ich9
Kok, Auke wrote:
I don't think that anyone besides you and maybe one or two others are
interested in doing this rewrite from scratch.
I count myself as one of those others. :) I don't think it's a rewrite
though; it's a rework.
The rest of us would
rather see something much more similar to
Jeff Garzik wrote:
Kok, Auke wrote:
1a) We post an e1000e driver that implements support for all 8257x
(ich8/9, es2lan etc) devices.
1b) We post a patch that drops support for all of these devices in the
form of a pci-ID removal (no code removed) for e1000.
2) we post patches that remove code
Kok, Auke wrote:
1a) We post an e1000e driver that implements support for all 8257x
(ich8/9, es2lan etc) devices.
1b) We post a patch that drops support for all of these devices in the
form of a pci-ID removal (no code removed) for e1000.
2) we post patches that remove code support for non-825
Kok, Auke wrote:
Christoph Hellwig wrote:
On Fri, Jun 29, 2007 at 07:31:55PM -0700, Kok, Auke wrote:
all the pci-express adapters that are supported are extremely similar:
- they all support 2 queues
- the register sets are (almost entirely) identical
- there is minimal feature variance betwee
Christoph Hellwig wrote:
On Fri, Jun 29, 2007 at 07:31:55PM -0700, Kok, Auke wrote:
all the pci-express adapters that are supported are extremely similar:
- they all support 2 queues
- the register sets are (almost entirely) identical
- there is minimal feature variance between 82571/2/3, esb2l
24 matches
Mail list logo
