linux-kernel - Re: Please pull 'revert-libertas' branch of wireless-2.6 (was Re: Please pull 'libertas' branch of wireless-2.6)

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:	Tue, 08 May 2007 18:28:50 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Matt Mackall <mpm@...enic.com>
CC:	Jeff Garzik <jeff@...zik.org>,
	"John W. Linville" <linville@...driver.com>,
	Dan Williams <dcbw@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-wireless@...r.kernel.org, marcelo@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Please pull 'revert-libertas' branch of wireless-2.6 (was Re:
 Please pull 'libertas' branch of wireless-2.6)

Matt Mackall wrote:
> On Mon, May 07, 2007 at 11:22:34AM -0400, Jeff Garzik wrote:

>>For my part, I _did_ review it.  Twice.  Once in the early days, and 
>>once when I pulled it into my netdev-2.6.git tree.  libertas needs the 
>>changes mentioned in this thread.  But the driver is in workable shape 
>>to be USED while being improved.  I strongly dislike people being cowed 
>>into not merging a driver for years, because the driver in question does 
>>not meet Christoph's idea of perfection.
> 
> 
> It's a shame to expose new ABI bits that we expect to change to
> mainline. Getting rid of obsolete interfaces is next to impossible so
> the introduction of new interfaces really does warrant serious
> consideration.
> 
> Can we come up with a scheme to keep the new ioctls introduced by this
> driver from leaking over into distro-land before they get reworked?
> Like preemptively adding a deprecation printk?

And it isn't only ioctls, but just having code there to set a bad
example, and added overhead of maintaining APIs used by the
driver.

Two things on top of a lot of people's pet peeves list are lack of
good review bandwidth, and poor driver code! So it is sad this was
merged without Christoph's comments being addressed. "it works for
me, we can fix it later" is probably a big reason for quality
problems of some parts of the kernel.

As for Christoph's idea of perfection... it usually isn't a bad
thing. And he is quite reasonable if you explain your good reason
to disagree or do something differently. The attitude of ignoring
comments can be really demotivating for a reviewer.

-- 
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/