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

On Mon, May 07, 2007 at 11:22:34AM -0400, Jeff Garzik wrote:
John W. Linville wrote:
On Mon, May 07, 2007 at 08:03:43AM -0400, Dan Williams wrote:
On Mon, 2007-05-07 at 11:41 +0100, Christoph Hellwig wrote:

Of course it's not anywhere near good shape. Almost all items from my
review were completely ignored, and we have another totoally substandard
wireless driver with crappy thread handling, a huge number of broken
private
ioctls and partially absymal codingstyle.

I've already updated libertas-2.6 git with a ton of updates for this.

In any case, lets push off any merge until 2.6.23 so the rest of the
comments can be dealt with:

Alright...Jeff, would you please pull the following branch for upstream
ASAP:

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git revert-libertas

This is leading from behind :/ We don't need to blow about in the wind
here. If you reviewed the driver in depth -- which I assumed because of
the trust placed in you as wireless maintainer -- then this situation
really should not be happening. You need to know the status of new
drivers you are pushing upstream: what work is left to do, what has been
done, what state the driver is in.

I view this request as a failure of the trust network :(

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?

--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
    ... anyone to review it. ... Also note that your patches are about superio, ... The list is dedicated to hardware monitoring. ... > Your pc87360 driver is all in one big piese of code, ...
    (Linux-Kernel)
  • Re: [lm-sensors] Hardware monitoring subsystem maintainer position is open
    ... their driver currently is. ... > 2) quick review could be done critical fixes only, ... > 3) review that goes deeper - check for interface conformity and all the ... Neither it does solve the maintainer problem, ...
    (Linux-Kernel)
  • Re: Distributed storage release.
    ... I am pleased to announce new distributed storage (DST) project release. ... although it would take a lot of time and the review ... This is the virtual block driver for virtio. ...
    (Linux-Kernel)
  • Re: [lm-sensors] Hardware monitoring subsystem maintainer position is open
    ... quick review could be done critical fixes only, driver goes to -mm ... review that goes deeper - check for interface conformity and all the stuff which could break - fixes for non-critical stuff ... Person posts driver ...
    (Linux-Kernel)
  • Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2
    ... The driver needs to be reviewed before it is merged. ... five will-not-build errors in the kernel.org tree. ... Then I'll review it for merge. ... The reason why it was "ignored" is more likely a lack of time and/or ...
    (Linux-Kernel)