[Prism54-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Luis R. Rodriguez]

On Wed, Sep 29, 2004 at 09:10:08AM +0200, Vladimir Kondratiev wrote:
> On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote:
> LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
> LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
> LR> > LR> RFC: what are the chances we can implement our own generic
>  "softmac" that may LR> > LR> be usable by the different chipsets out there?
> LR> >
> LR> > Coming days, I will submit "framework" consisting of stack based on
>  Dave's LR> > code and debug driver which will be able to imitate Rx. I have
>  working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces
>  stack-driver and LR> > stack-upper layers. It would be great if someone will
>  do MAC algorithms. I'll LR> > appreciate this for sure.
> LR>
> LR> But would it be possible? Would it work, if we write our own softmac
> LR> interface? Or are softmac interaces/libraries strictly dependent on a
> LR> chipset being used?
> LR>
> LR>  Luis
> LR>
> In idea yes, 802.11 stack should serve any low level driver provided it can 
> Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The 
> difference is, 802.11 stack is not written yet, we need to make sure we do it 
> in smart way and with reasonable assumptions about what low level driver can 
> do.
> 
> Thus far, I assume, low level driver (and NIC, of course) can:
> -Tx/Rx arbitrary data and management packets. Control frames generated by NIC.
> -NIC can perform scanning and report beacons or probe resp. to the stack.
> -NIC can report some basic PHY data per packet: rate, RSSI, maybe something 
> else.
> -NIC accept some basic PHY data per packet on Tx: rate, retry count, 
> protection, maybe Tx power and some others
> -NIC can do crypto transformations on both Tx and Rx. For this, crypto key 
> need be provided per packet for Tx and some ,mechanism to provide key for 
> each peer need to be established for Rx.
> -NIC may choose to not do fragmentation/reassembly, stack will handle it.
> -NIC may have many Tx queues for QoS, it will be able to start/stop each one.
> 
> To not raise unsupported expectations: 802.11 stack is only skeleton for now. 
> I will do interface parts first. For actual algorithms to handle managements 
> flows, help required. But, I believe it is wise to write these algorithms 
> once for this stack rather to implement whole stack with each driver.

OK great, then I'll try working Conexant to push for this as our goal
for a softmac driver for linux. Currently they use their own libraries
(not even a separate module, as atheros with its HAL). This is
unacceptable for kernel inclusion and that simply just sucks. Hopefully
this will be possible :)

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mcgrof.com/pipermail/prism54-devel/attachments/20040929/689bd071/attachment.pgp