netdev
[Top] [All Lists]

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

To: Vladimir Kondratiev <vkondra@xxxxxxx>
Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Thu, 02 Sep 2004 16:33:31 -0400
Cc: netdev@xxxxxxxxxxx, Denis Vlasenko <vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Jean Tourrilhes <jt@xxxxxxxxxxxxxxxxxx>, Jouni Malinen <jkmaline@xxxxxxxxx>, acx100-devel@xxxxxxxxxxxxxxxxxxxxx, prism54-devel@xxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxx>
In-reply-to: <200409022324.43117.vkondra@mail.ru>
References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4134C1A7.50600@pobox.com> <200409022324.43117.vkondra@mail.ru>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Vladimir Kondratiev wrote:
Jeff,

On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
JG> Denis Vlasenko wrote:
JG> > I think 'senior' network guys are in position to decide upon which
JG> > of currently available 802.11 stacks we should continue to work.
JG> > (Atheros has one, said to be derived from BSD, is there any others?)
JG>
JG>
JG> Already have. Start with the code in wireless-2.6 -- HostAP -- and use
JG> DaveM's 802.11 stack template as a model for actually integrating 802.11
JG> very tightly with the rest of the net stack.
JG>
JG>
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
0211.tar.bz2


Is this stack the main one that is going to be used? I.e. if I am working on driver for next generation .11 card - should I try to use it, request/submitt missing features etc.? Or should I use wireless extensions?

DaveM's code is a template for how a wireless stack would look when properly and fully integrated into the net core.


Although JeanT and I disagree about this, I am less interested in backwards compatibility than I am about making wireless a "first class citizen" in the kernel. As I have proven with kcompat (http://sf.net/projects/gkernel/) you can be backwards compatible while still evolving the current kernel driver API to meet current design needs.

        Jeff



<Prev in Thread] Current Thread [Next in Thread>