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: <1180538928.17163.10.camel@xo-28-0B-88.localdomain>
Date:	Wed, 30 May 2007 11:28:48 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Please pull 'libertas' branch of wireless-2.6

On Wed, 2007-05-30 at 10:07 -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> > Lots of stuff here...probably best for 2.6.23...
> 
> Is this best for Linux users... or just easy for developers?
> 
> Won't putting off all these fixes until 2.6.23 leave the driver released 
> in 2.6.22 in shoddy shape?

Not really; it more or less works there.  What's gone on since then is
general driver cleanup (Christoph's comments and more), splitting the
driver so that other bus types can use it (SDIO for example once
Pierre's SDIO patches get upstream), wireless extensions fixes, etc.

> libertas is upstream now, so we cannot pretend that the driver is 
> completely independent from upstream release cycles and maintenance.

True, but some of the stuff in here I didn't think would be suitable
during an -rc cycle, for example the driver splitting and the cleanups
that don't impact function at all, but are good to do nonetheless.

> libertas fixes should go upstream immediately, since we are in a bugfix 
> cycle, and since libertas (from upstream perspective) is about to make 
> its big debut on the world stage.

If you think all the bits from this should just go to 2.6.22, that's
fine with me.  But I don't feel comfortable making that call given what
I thought were the constraints on pushing changes through during an rc
cycle.  When the merge window was open, we backported critical bug fixes
and necessary merge-requirement cleanups to the code in linville's tree,
but avoided changes that didn't impact function.

Dan


-
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