[Top] [All Lists]

Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.1

To: acx100-devel@xxxxxxxxxxxxxxxxxxxxx, Vladimir Kondratiev <vkondra@xxxxxxx>, netdev@xxxxxxxxxxx
Subject: Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack
From: Denis Vlasenko <vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 9 Sep 2004 00:19:21 +0300
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, acx100-devel@xxxxxxxxxxxxxxxxxxxxx, greg chesson <greg@xxxxxxxxxxx>, hadi@xxxxxxxxxx, jgarzik@xxxxxxxxx, jkmaline@xxxxxxxxx, prism54-devel@xxxxxxxxxxx, sam@xxxxxxxxx
In-reply-to: <200409082251.45771.vkondra@xxxxxxx>
References: <200408312111.02438.vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <413F2D33.1000508@xxxxxxxxxxx> <200409082251.45771.vkondra@xxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.5.4
On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote:
> Greg,
> you missed one important point. Besides data packets, that every driver now
> convert .11<->.3 using almost the same code, there is whole story of
> management. Many modern cards are "softmac" and do all management on host.
> I see no point for every driver to implement its own scanning and
> association. It is simply waste of resources.

This is exactly what I meant. We need generic 802.11 idioc^W management
handling. And maybe also tx rate control, ACK/retries for "completely-softmac"
cards like Atheros.

Full spectrum of possible fullmac......softmac designs are not trivial
to handle...

> To make step forward, I suggest the following:
> 1. Dave's code is at least year old. someone need to start maintain it,
> starting with update for current kernel infrastructure. Get it compile and
> load for 2.6.9, for example.

/me runs away and hides

> 2. To debug stack, you don't need real driver. I can write dummy .11 driver
> that will silently discard all Tx, and will provide some way for user level
> tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it
> is sufficient. Later, when it will come to timing, performance etc, it will
> be easy to strip some real driver.

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