netdev - Re: [PATCH] firmware: convert acenic driver to request

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: <4859371F.8090404@garzik.org>
Date:	Wed, 18 Jun 2008 12:26:07 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	Jes Sorensen <jes@...ined-monkey.org>, netdev@...r.kernel.org,
	jaswinder@...radead.org
Subject: Re: [PATCH] firmware: convert acenic driver to request_firmware()

David Woodhouse wrote:
> I believe you didn't respond to this, but just spouted the same
> complaint at another patch which was posted for review, without even
> seeming to have _looked_ at the part of that patch which really needed
> reviewing.
> 
> This has needed doing for a long time, and I've finally got off my
> posterior and started working on it. If you wanted it done precisely
> your way, you could always have done it yourself. As it is, we have a
> minor disagreement about some of the details, but it still needs doing.
> And since it still seems to be me doing it and not you, I'm still doing
> it the way I believe is best.

So, if you get an unhappy review, the reviewer must do your work for 
you?  That doesn't work for university students, and that doesn't fly here.

We are in the part of the Linux kernel coding process called 'taking 
feedback'.

The onus is on YOU to make your work friendly to both users and developers.

You can do whatever you please, but if its not friendly to Linux users 
(our customers) or Linux developers, it's mostly dead in the water. 
Those are my concerns, which you repeatedly fail to address.

For Pete's sake, you haven't even been able to admit the obvious:  these 
patches have a major, major chance of producing a non-working driver for 
users.

Your patch and your goal mean nothing if Linux users wind up having to 
jump through a dozen new hoops, just to ensure that a driver working 
yesterday continues to work today.  That's just plain bad engineering, 
no matter how noble the goal.

	Jeff

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