"It doesn't seem to pull any dependency nor affect any other external piece of code unless I'm missing something, so it's a perfect example of what we've been discussing back then: there is just no point not merging it at any time right ? :-)" Benjamin Herrenschmidt summarized his request that the iwl4965 driver be merged into the 2.6.23 kernel late in the release cycle, outside of the standard two week merge window. John Linville answered, "it is queued for 2.6.24. I'm not even sure it was originally posted in time for the 2.6.23 merge window, but even if it was there was a lot of opposition to merging it until fairly recently. In fact, I'm sure there are still some wireless developers that are less than happy about merging it now." When asked what the opposition was about, he referred to a discussion on the netdev mailing list and explained:
"There have been a lot of spats about how functionality has been partitioned between the driver and the firmware, issues with how the driver tries to do things that either ought to be in mac80211 or not done at all, and some random complaints about ugliness like '#include "../../../net/mac80211/blah.h"', etc. There is still plenty of work to be done on this driver, but as you point out we are better-off with it in the kernel than with it out."
From: Benjamin Herrenschmidt <benh@...>
Subject: iwl4965 and driver merging policy
Date: Sep 27, 9:39 pm 2007
Hi !
Just a little question in the light of the discussion we had at Kernel
Summit about merging drivers upstream (and here, I strongly agree with
Linus, hence my message).
I just got that new T61 laptop which happens to have an iwl4xxx chip.
The distro I installed on it (ubuntu) has a driver for it. I suspect
others do too and most users get it from some random external tree and
use it.
Thus my question, why are we about to release 2.6.23 without it ?
It doesn't seem to pull any depedency nor affect any other external
piece of code unless I'm missing something, so it's a perfect example of
what we've been discussing back then: there is just no point not merging
it at any time right ? :-)
Cheers,
Ben.
-
From: John W. Linville <linville@...>
Subject: Re: iwl4965 and driver merging policy
Date: Sep 27, 10:30 pm 2007
On Fri, Sep 28, 2007 at 11:39:27AM +1000, Benjamin Herrenschmidt wrote:
> Just a little question in the light of the discussion we had at Kernel
> Summit about merging drivers upstream (and here, I strongly agree with
> Linus, hence my message).
You must not have been watching me SPAM netdev for the past two
weeks. :-)
> I just got that new T61 laptop which happens to have an iwl4xxx chip.
> The distro I installed on it (ubuntu) has a driver for it. I suspect
> others do too and most users get it from some random external tree and
> use it.
>
> Thus my question, why are we about to release 2.6.23 without it ?
>
> It doesn't seem to pull any depedency nor affect any other external
> piece of code unless I'm missing something, so it's a perfect example of
> what we've been discussing back then: there is just no point not merging
> it at any time right ? :-)
It is queued for 2.6.24. I'm not even sure it was originally posted
in time for the 2.6.23 merge window, but even if it was there was
a lot of opposition to merging it until fairly recently. In fact,
I'm sure there are still some wireless developers that are less than
happy about merging it now.
Anyway, coming soon to a kernel near you...
John
--
John W. Linville
linville@tuxdriver.com
-
From: Benjamin Herrenschmidt <benh@...>
Subject: Re: iwl4965 and driver merging policy
Date: Sep 27, 11:15 pm 2007
On Thu, 2007-09-27 at 22:30 -0400, John W. Linville wrote:
> > It doesn't seem to pull any depedency nor affect any other external
> > piece of code unless I'm missing something, so it's a perfect
> example of
> > what we've been discussing back then: there is just no point not
> merging
> > it at any time right ? :-)
>
> It is queued for 2.6.24. I'm not even sure it was originally posted
> in time for the 2.6.23 merge window, but even if it was there was
> a lot of opposition to merging it until fairly recently. In fact,
> I'm sure there are still some wireless developers that are less than
> happy about merging it now.
>
> Anyway, coming soon to a kernel near you...
Allright, thanks. I was mostly trying to figure out where we standed
with this whole idea that driver additions were not necessarily
constrainted by the merge window (which I think is fair to do) and this
looked like a good example to pick since it affects my new laptop :-)
Out of curiosity, what's the main source of opposition ? Since it's
being shipped by distro or built out of tree by most users -anyway-, I
think it's pretty clear that we'd be better off having it merged asap
rather than trying to figure out what random version was included by
users/distros and try to support it, in addition to wider exposure & all
the yadada of being upstream in the first place.
Ben.
-
From: John W. Linville <linville@...>
Subject: Re: iwl4965 and driver merging policy
Date: Sep 28, 9:28 am 2007
On Fri, Sep 28, 2007 at 01:15:23PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-09-27 at 22:30 -0400, John W. Linville wrote:
> > I'm sure there are still some wireless developers that are less than
> > happy about merging it now.
> Out of curiosity, what's the main source of opposition ? Since it's
> being shipped by distro or built out of tree by most users -anyway-, I
> think it's pretty clear that we'd be better off having it merged asap
> rather than trying to figure out what random version was included by
> users/distros and try to support it, in addition to wider exposure & all
> the yadada of being upstream in the first place.
There have been a lot of spats about how functionality has been
partitioned between the driver and the firmware, issues with how the
driver tries to do things that either ought to be in mac80211 or not
done at all, and some random complaints about ugliness like '#include
"../../../net/mac80211/blah.h"', etc. There is still plenty of work
to be done on this driver, but as you point out we are better-off
with it in the kernel than with it out.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
-
Better not...
You better drop your idea.
1. The License is too complex for some developers (3 Clauses!)
2. I've strong concerncs about it. Let me point out why.
-- LICENSE--
Copyright (c) 2006, Intel Corporation.
All rights reserved.
Redistribution. Redistribution and use in binary form, without
modification, are permitted provided that the following conditions are
met:
* Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission.
* No reverse engineering, decompilation, or disassembly of this software is permitted.
Limited patent license. Intel Corporation grants a world-wide,royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone, or in combination with an operating system licensed under an approved Open
Source license as listed by the Open Source Initiative at
http://opensource.org/licenses. The patent license shall not apply to any other combinations which include this software. No hardware per se is licensed hereunder.
DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-- License --
* No reverse engineering, decompilation, or disassembly of this software is permitted.
That is the point why you should better start using a BSD or a reversed driver then this crap.
Why is it so meaningfull? Well normal users WONT decompile it but what happens if your Testkernel with this driver produces a coredump wich gets analysed by you? That's debugging..you brocke the rule (Nr. 3)!
Furthermore whoever wrote this License as INTEL is nuts or dumb. Clause 2 and 3 are mutually exclusive.
If you're not allowed to MODIFY it how should you be able to produce a derivated work? That just makes no sense at all..
And: Have fun "porting" it to other architectures (well I bet that was never planed... so far... right?)
That "no reverse
That "no reverse engineering, decompilation, or disassembly of this software is permitted" is certainly a pretty lame clause all right. Especially as they are providing the source code. Perhaps it refers to a binary blob bit?
I would also suspect it is not enforceable as I believe those are not something rights that the copyright law gives the creator exclusive access to (and thus the ability to dictate who else gets to do them).
However, I don't quite follow your argument regarding two and three being in conflict. Perhaps you meant one and two are in conflict? The former says you have to keep "copyright intel..." and the second says you can't have "copyright intel..." (assuming that is an endorsement) in a derivative work.
Only applies to the firmware
This license only applies to the firmware blob that gets loaded onto the wireless card. The rest of the driver, that interacts with the kernel is all GPL (parts are dual licensed under BSD as well).
Isn't that the firmware's
Isn't that the firmware's license?
The driver looks GPL to me
referring to outdated code
Congrats on finding the old license from the binary blob which isn't even discussed here and has nothing to do with iwlwifi in the kernel...
Merge it, and then ipw3945!
Make my life better.
Works fine for me
I've been using this driver since its early beginnings and it has always proved reliable. Sure I'm not a huge fan of the binary firmware, but coming from Apple's (or better, Broadcom's) Airport Extreme and its difficult bcm43xx driver this is heaven.
So please merge it soon enough!