Steps for netdev-2.6 inclusion?

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

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

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.

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.)

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

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 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.

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

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