David S. Miller wrote:
On Sun, 12 Sep 2004 20:09:08 -0400
Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
Vladimir Kondratiev wrote:
To inform about status:
I started to work on idea of 802.11 generic stack. I start from code by Dave.
This far I fixed it to compile for 2.6 (Makefile and couple of syntax
errors).
I am going to implement minimum functionality, at this stage I will somehow
publish the project. Anyone can suggest what it the right solution for
hosting? Sourceforge? Something else?
I can put it into the wireless-2.6 queue, which is where I would prefer
that work on a generic 802.11 stack went.
This is fine with me as well.
I have seen two paths that need to occur:
1) Creation of a generic 802.11 frame handling stack (management, data,
etc.) sufficient to do .3 to .11 conversion, .11 fragmentation, state
machine, etc.
2) Tight integration of a .11 stack into the kernel
The first step can occur with minimal changes to the rest of the
kernel, isolated completely within drivers/net/wireless. Once a stack
is there, all the drivers there can be adapted to use that. This would
seem reasonable to pull into the 2.6 stable series.
The second step will likely require more invasive changes to other parts
of the networking stack and I hadn't thought such changes would be
considered for 2.6.
Am I incorrect in the above?
We have been cleaning up the ipw2200/ipw2100 and their corresponding
ieee80211 stack so that it could then be used with the other wifi
drivers (adapting it to add back in features from HostAP that are
currently stub'd out) in a non-intrusive way (we would like to get ipw*
merged in soon). We have a bk tree for this cloned from wireless-2.6
avialable at ipw.bkbits.net/ipw-2.6.
Right now a driver can register with netdev's xmit to receive the
ethernet frame and then pass it to ieee80211_skb_to_txb() to transform
it into a chain of 802.11 fragments (encrypted if configured to do so)
which the device can then pass to the HW. I don't like the way the
skb_to_txb transform occurs, but its working right now. The next level
of integration would be to have the device driver register an ieee80211
stack callback as the xmit handler, and then register a .11 xmit with
the ieee80211 stack.
Anyway, based on what I had read previously on this group, the sequence
of steps I understood needing to be followed were:
0) Get the ipw2100 and ipw2200 drivers functionally complete so that end
users can fully utilize that hardware.
1) Create generic ieee80211 frame handling stack. HW specific piece
should be limited to Tx/Rx of raw frames as much as possible (while
supporting drivers that can not do full 802.11 frame tx/rx). For
nonintrusive inclusion in kernel, this would be achieved through calls
into the ieee80211 stack from the driver vs. addition of netdev entry
points. To date this has been achieved by adding infrastructure into
either the ipw2100 or ipw2200 project, then merging it into ieee80211 so
that the other project could leverage it.
2) Adapt other drivers besides ipw2100 and ipw2200 to use the stack
3) Once 1 and 2 are stabilized, begin restructuring the entry points to
more tightly integrate the .11 handling into the netdev core.
One area where I wasn't sure on how invasive it would be for stack
optimizations deal with 802.11 fragmentation and encryption of said
fragments such that TCP retries do not require
re-fragmentation/encryption when host based enc/frag is enabled.
The next potentially invasive area is the addition of TGe support which
Vladimir has discussed previously.
We based the current ieee80211 stack in part on the Host AP stack. In
looking through the madwifi stack, there are traights that it carries
that would be nice to be able to use as well moving forward -- whether
through code (CVS madwifi is licensed under a GPL compatible BSD
license) or aspects of design.
The whole of the ieee80211 stack (and ipw2100/ipw2200 drivers) are
licensed under GPL version 2.
James
|