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
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 c
Is anyone working on this stack? I asked Dave, he is hot working on it. Or is this code dead? which JG> > JG> > of currently available 802.11 stacks we should continue to work. JG> > JG> > (Atheros h
Vladimir Kondratiev wrote: Is anyone working on this stack? I asked Dave, he is hot working on it. Or is this code dead? Nobody is actively working on that stack AFAIK. Jeff
On Aug 31, 2004, at 11:11 AM, Denis Vlasenko wrote: Hi all, It looks like acx100 approaches state when we can consider it's inclusion into mainline kernel. Some background information: acx100 and acx
could you please provide URL where this code is hosted? I know it only as part of madwifi. Vladimir Attachment: pgpWLjCZSleJI.pgp Description: PGP signature
could you please provide URL where this code is hosted? I know it only as part of madwifi. The madwifi project is hosted at sourceforge http;//sourceforge.net/projects/madwifi. Source code is current
Sam, I've told you multiple times why your stack isn't a good starting point. It isn't implemented as a true network stack, like IPV4, Appletalk, etc. Instead it's a gross input packet hooked packet
Actually, this is the first time you've said anything to me about this code. We corresponded intensely for about a week 2+ years ago after which you declared you now knew how to "write an 802.11 stac
I do remember telling you how much I was against this element of your design. At the time, you were not willing to rearchitect things and you were in a sort-of bug-fix only mode. It means passing the
Oh really? What about eth_type_trans()? It is not implemented as a true network stack. Many drivers call it, but it is a gross input packet hooked eater thing that's an ugly wart bolted onto the side
It determines the protocol type from the ethernet header fields. It is a simple shorthand header field fetcher, not a protocol stack. You would need a eth80211_type_trans() for wireless drivers too,
I certainly agree with you about getting the base design right. Where are these bits you refer to? g David S. Miller wrote: On Tue, 07 Sep 2004 10:03:41 -0700 greg chesson <greg@xxxxxxxxxxx> wrote: W
Or as Andi has been suggesting for sometime, not invoke it all ;-> This is possible if the DMA descriptor already has all the info needed (quiet a few modern hardware can be programmed to do this). .
You guys are too serious and, I believe, missed the real points. 1. There is a need in the OS for a "service" to convert between .11 and .3 packet formats. It should be designed for hw-independence.
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 al
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