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]
Date:	Sat, 07 Jul 2007 14:54:11 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Jeff Garzik <jeff@...zik.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Grover <andy.grover@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jason Lunz <lunz@...lexsecurity.com>,
	Mark McLoughlin <markmc@...hat.com>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	"Ronciak, John" <john.ronciak@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	'Stephen Hemminger' <shemminger@...ux-foundation.org>,
	Andy Gospodarek <andy@...yhouse.net>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
 ?)

Francois Romieu wrote:
> Kok, Auke <auke-jan.h.kok@...el.com> :
>> 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 will take significant time, is silly since it's almost identical to 
>> ich8 etc..
>>
>> I don't think that anyone besides you and maybe one or two others are 
>> interested in doing this rewrite from scratch.
> 
> So far I'd say him and at least two others. Is it time to count them ?
> 
> Everybody is cool and polite but after a week of discussion this is
> going nowhere.

It is really hard to stay polite for me now. After we were told to clean up the 
driver and implement things like feature flags and organize all the various 
hardware dependent bits, we did exactly that. And now we're told to rewrite the 
driver from scratch. ("thanks for the effort but no thanks, do this instead").

If that does not make your hair on the back of your neck stand up...

I politely suggested a middle way that would allows us to continue working on 
the driver and take it to the next step. This would in my opinion be the least 
destructive plan and get us moving forward quickly. Jeff's alternative plan can 
set us back another year. Perhaps it won't, but I fear that it will, and it will 
  be a hard thing to sell to my group and other parties.

I agree that rewriting drivers that are bad from scratch is a good thing. But in 
this case we're talking about a driver with a good reputation that has 
functioned really well for everyone for as long as it's out there. Perhaps you 
disagree on this, but lets just agree on that e1000 never really broke in the 
last 7 years even though we added over 50 different type of adapters to it, and 
it's still performance wise a good driver.

As a matter of fact, I find it hard to believe that e1000 has a bad reputation. 
Almost all of the direct feedback that I get from people using e1000 is 
positive. We regularly get good feedback on our response rate too.

We as a group are committed to keep repairing and improving e1000 and I think 
that we have shown our good intent with some of the stuff that we've recently 
shown. I think it's also polite to let us do our work and work *with* us, 
instead of dumping our ideas ("I like the gist of it, but") and basically 
sending us off with nothing. And that means that the linux community also is 
stuck with nothing.

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.


Auke

-
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