Steps for netdev-2.6 inclusion?

Steps for netdev-2.6 inclusion?

[James Ketrenos]

Ok, its been a long time coming, but it appears the ipw* wireless drivers are to 
the point where being more proactive at getting them into the kernel is 
appropriate (at least based on the frequency of emails I'm getting of 'why isn't 
this in mainline?')

So, what would be the set of steps required to get a version in the queue for 
inclusion?

The drivers we have are the ipw2100 (supporting the Intel PRO/Wireless 2100 
Network Connection adapter) and ipw2200 (supporting the Intel PRO/Wireless 
2200BG and 2915ABG Network Connection adapters).  There is also a shared generic 
ieee 802.11 stack (ieee80211*.ko) supporting 802.11b, g, and a for BSS and IBSS 
modes.

The ipw2100 recently was stamped 1.0.0, which means we've put it through a 
validation and stabalization phase.  As we want to try and ensure end users 
don't have to spend all night fighting with their wireless connection just 
because they've updated the kernel, we've adopted the following version 
numbering scheme for the ipw* drivers in the form of of x.y.z, where:

  .z increases from snapshot to snapshot (pushed out as tarballs on SourceForge)
  .y increases (and sets .z to 0) when a snapshot has gone through a regression 
validation cycle.
  .x increases if there are significant functionality changes to the driver.

The idea is to then only have x.y.0 (stable/tested) versions go out for wider 
distribution (kernel inclusion).

For those that are curious, the tip of development for the ipw2100, ipw2200, and 
ieee80211 stack is available at bk://ipw.bkbits.net/ipw-2.6.

Given what I described above, would it be most appropriate to create a 
ipw-2.6-stable bk tree with the parent as netdev-2.6 that we put the stable 
versions of the ipw* drivers into, and then request that be pulled?  The ipw-2.6 
tree could then continue to represent the development tip.  I've searched around 
for some BKMs on this, but haven't found a whole lot.

The ipw2100 1.0.0 snapshot (and newer versions) can be found at 
http://ipw2100.sf.net/#downloads.  The latest ipw2200 snapshot (0.15) is 
available at http://ipw2200.sf.net/#downloads.

Also, we have a Bugzilla database setup for the above drivers at 
http://bughost.org for those that are curious about current remaining issues, etc.

Thanks,
James

Re: Steps for netdev-2.6 inclusion?

[Jeff Garzik]

It's fairly easy, just email me and netdev the patch for inclusion, and 
it'll get reviewed.

Once review issues are addressed, I'll merge it immediately, which 
causes it to be automatically propagated to Andrew Morton's -mm tree for 
testing.

Once consensus agrees that we can push this + HostAP upstream, that's an 
easy 10-minute task.

One potential showstopper is firmware crapola:  I'm concerned about a 
situation where we have drivers in the kernel, but the firmware must be 
downloaded from SourceForge or somesuch.  IOW, the kernel driver as-is 
is useless without a differently-licensed firmware.

Comments?

	Jeff

Re: Steps for netdev-2.6 inclusion?

[James Ketrenos]

Jeff Garzik wrote:

> It's fairly easy, just email me and netdev the patch for inclusion, 
> and it'll get reviewed.

Should I break the patch into the three components (ipw2100, ipw2200, 
and ieee80211) ? or just one huge patch?  Not sure what you and others 
would prefer.

> Once review issues are addressed, I'll merge it immediately, which 
> causes it to be automatically propagated to Andrew Morton's -mm tree 
> for testing.
>
> Once consensus agrees that we can push this + HostAP upstream, that's 
> an easy 10-minute task.
>
> One potential showstopper is firmware crapola:  I'm concerned about a 
> situation where we have drivers in the kernel, but the firmware must 
> be downloaded from SourceForge or somesuch.

The firmware doesn't have to be downloaded from Sourceforge, but it does 
need to exist on the system, just as iwconfig needs to exist if you want 
to be able to configure your wireless card.  The user can get the 
firmware from Sourceforge, or have it installed by their distribution or 
package management system, have it on their Knoppix CD, etc. 

Loading the driver without the firmware (or hotplug being enabled) won't 
take down the machine -- it will just print a kernel log message saying 
the firmware can't be found.

For some common questions and answers on the redistribution of the 
license, see http://intel.com/support/wireless/wlan/sb/cs-016675.htm

Regarding the topic of loading firmware from disk... the firmware_class 
subsystem was designed for this purpose.

 From linux/Documentation/firmware_class/README:

------------------
 Why:
 ---

 Today, the most extended way to use firmware in the Linux kernel is linking
 it statically in a header file. Which has political and technical issues:

  1) Some firmware is not legal to redistribute.
  2) The firmware occupies memory permanently, even though it often is just
     used once.
  3) Some people, like the Debian crowd, don't consider some firmware free
     enough and remove entire drivers (e.g.: keyspan).
-------------------

Point one is partially applicable -- redistribution of the ipw firmware 
*is* legal, but due to the terms of the GPL, inclusion in the kernel is 
not possible (the firmware can't be licensed GPL, and so static 
inclusion in the driver as a header binary is impossible.)  So, the 
firmware must be loaded onto the NIC from some other storage medium.

The second point from the firmware_class's README is also valid 
(although the current state of suspend/resume necessitates a 
pre-allocated memory buffer in the driver.  Once that issue is remedied, 
the host will be able to free up a reasonable amount of memory that is 
otherwise unnecessary.)

> IOW, the kernel driver as-is is useless without a differently-licensed 
> firmware.

Wireless (and many other kernel components) are arguably useless without 
user space utilities that must be downloaded, built, and installed.  So 
the issue of having to download something, or have some other 
pre-requisite met before the driver is useful/functional is not unique 
to this driver.

James

Re: Steps for netdev-2.6 inclusion?

[Christoph Hellwig]

On Thu, Dec 02, 2004 at 02:11:52PM -0600, James Ketrenos wrote:
> Jeff Garzik wrote:
> 
> >It's fairly easy, just email me and netdev the patch for inclusion, 
> >and it'll get reviewed.
> 
> Should I break the patch into the three components (ipw2100, ipw2200, 
> and ieee80211) ? or just one huge patch?  Not sure what you and others 
> would prefer.

Please split it in three parts.  And most importantly integrate your
ieee80211 code with the hostap code in Jeff's queue, we really don't
want two copies of it.

> The firmware doesn't have to be downloaded from Sourceforge, but it does 
> need to exist on the system, just as iwconfig needs to exist if you want 
> to be able to configure your wireless card.  The user can get the 
> firmware from Sourceforge, or have it installed by their distribution or 
> package management system, have it on their Knoppix CD, etc. 

The problem is again that the license for it is horrible multi page
legaleese.  Please change it to a simple license that allows completely
free redistribution and modification of the binaries.

Re: Steps for netdev-2.6 inclusion?

[Jeff Garzik]

James Ketrenos wrote:
> 
> Ok, its been a long time coming, but it appears the ipw* wireless 
> drivers are to the point where being more proactive at getting them into 
> the kernel is appropriate (at least based on the frequency of emails I'm 
> getting of 'why isn't this in mainline?')
> 
> So, what would be the set of steps required to get a version in the 
> queue for inclusion?

Any updates?  Where do we stand with this?

I would suggest sending a patch for each driver, diff'd against -mm 
(which auto-includes my netdev-2.6 and wireless-2.6 queues).

	Jeff

Re: Steps for netdev-2.6 inclusion?

[James Ketrenos]

Jeff Garzik wrote:

> James Ketrenos wrote:
>
>>
>> Ok, its been a long time coming, but it appears the ipw* wireless 
>> drivers are to the point where being more proactive at getting them 
>> into the kernel is appropriate (at least based on the frequency of 
>> emails I'm getting of 'why isn't this in mainline?')
>>
>> So, what would be the set of steps required to get a version in the 
>> queue for inclusion?
>
>
> Any updates?  Where do we stand with this?

Sorry -- we had some fires to put out, and then Christmas kicked in :)

We're rolling in a couple fixes into the 2200 driver this week for 
ad-hoc mode and will then send out the patches to this list.

Thanks,
James

>
> I would suggest sending a patch for each driver, diff'd against -mm 
> (which auto-includes my netdev-2.6 and wireless-2.6 queues).
>
>     Jeff
>
>
>