From: Denis V. <vd...@po...> - 2004-08-31 18:16:01
|
Hi all, It looks like acx100 approaches state when we can consider it's inclusion into mainline kernel. Some background information: acx100 and acx111 hardware is a bit like Atheros and possibly prism54 "softmac": it handles mostly low-level rx/tx stuff, leaving 802.11 stack implementation up to OS (which is good. To have largish potentially buggy binary-only firmware to cope with is a nightmare). I think what acx100 devel is working on can be best described as "yet another 802.11 stack implementation". This is not ok. I think we definitely need generic 802.11 stack, with individual drivers providing only needed callbacks, just like it is done for wired eth drivers. I think 'senior' network guys are in position to decide upon which of currently available 802.11 stacks we should continue to work. (Atheros has one, said to be derived from BSD, is there any others?) Give us some guidance please... -- vda |
From: Jeff G. <jg...@po...> - 2004-08-31 18:21:59
|
Denis Vlasenko wrote: > I think 'senior' network guys are in position to decide upon which > of currently available 802.11 stacks we should continue to work. > (Atheros has one, said to be derived from BSD, is there any others?) Already have. Start with the code in wireless-2.6 -- HostAP -- and use DaveM's 802.11 stack template as a model for actually integrating 802.11 very tightly with the rest of the net stack. http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 Jeff |
From: Vladimir K. <vk...@ma...> - 2004-08-31 19:15:15
|
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 JG> JG> Jeff This stack raises many questions. The very idea to implement generic softmac is pretty good. So, first questions: =2D it defines structures that was present in Jean's wireless extensions. S= o,=20 will it replace Jean's wireless extensions, merge with it, or some other=20 relationship? Partually, I don't like to see definitions for .11 header and= =20 field constants in 2 includes. =2D QoS stuff is not defined. I suppose recent cards will all support WME a= nd/or=20 TGe. It is easy to add "QoS control" field to header and new frame types, b= ut=20 it is harder to formally define how PHY should handle it. And, TGe is big=20 story on itself, with all its HCCA, block ack, etc. I also think that QoS, = as=20 it is defined in TGe, required driver to have several tx queues and=20 start/stop them separately. Is anyone working on it? I'll be glad to join. =2D Security is not up-to date either. We need .1x, EAS, TKIP etc. This nee= d to=20 be done for modern cards to use this infrastructure. |
From: <mc...@ru...> - 2004-08-31 21:37:25
|
On Tue, Aug 31, 2004 at 10:14:38PM +0300, Vladimir Kondratiev wrote: > 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 JG> > JG> Jeff > > This stack raises many questions. > > The very idea to implement generic softmac is pretty good. > > So, first questions: > > - it defines structures that was present in Jean's wireless extensions. So, > will it replace Jean's wireless extensions, merge with it, or some other > relationship? Partually, I don't like to see definitions for .11 header and > field constants in 2 includes. > > - QoS stuff is not defined. I suppose recent cards will all support WME and/or > TGe. It is easy to add "QoS control" field to header and new frame types, but > it is harder to formally define how PHY should handle it. And, TGe is big > story on itself, with all its HCCA, block ack, etc. I also think that QoS, as > it is defined in TGe, required driver to have several tx queues and > start/stop them separately. Is anyone working on it? I'll be glad to join. > > - Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to > be done for modern cards to use this infrastructure. This is handled by hostap wpa_supplicant now, which is going to be part of WE18. The question I think is whether somoene plans on re-doing it on wireless-2.6, since as you mentioned it seems WE are being redone on davem's patch. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E |
From: Vladimir K. <vk...@ma...> - 2004-08-31 22:07:28
Attachments:
tge.patch
|
<skip> http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 <skip> LR> > - QoS stuff is not defined. I suppose recent cards will all support WME and/or LR> > TGe. It is easy to add "QoS control" field to header and new frame types, but LR> > it is harder to formally define how PHY should handle it. And, TGe is big LR> > story on itself, with all its HCCA, block ack, etc. I also think that QoS, as LR> > it is defined in TGe, required driver to have several tx queues and LR> > start/stop them separately. Is anyone working on it? I'll be glad to join. LR> > I'd like to contribute easiest part of TGe, to start with something (against source mentioned above). I defined only frame formats and bits for fixed fields. |
From: Jouni M. <jkm...@cc...> - 2004-09-01 02:25:43
|
On Tue, Aug 31, 2004 at 05:37:19PM -0400, Luis R. Rodriguez wrote: > On Tue, Aug 31, 2004 at 10:14:38PM +0300, Vladimir Kondratiev wrote: > > - Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to > > be done for modern cards to use this infrastructure. > > This is handled by hostap wpa_supplicant now, which is going to be part > of WE18. The question I think is whether somoene plans on re-doing it on > wireless-2.6, since as you mentioned it seems WE are being redone on > davem's patch. This sounds somewhat confusing.. As far as WPA and IEEE 802.11i (RSN/WPA2) are concerned, there are number of different components involved. One part is in IEEE 802.11 data frame handling (TKIP, CCMP). This is implemented, e.g., in the current Host AP RX/TX paths more or less completely. The current implementation is still hardcoded to do this in software, so it would need to be extended to support offloading encryption to the wlan card since many of the modern cards have hardware (or combination of hardware/firmware) implementation of TKIP and CCMP. In addition, IEEE 802.11e will add some small changes to TKIP/CCMP processing; Host AP code has places for this for TX (mainly, setting priority value in the header). RX needs some more work because of possible reordering of packets with different priorities. This all lives in the generic 802.11 stack of the kernel. In addition to data encryption, IEEE 802.11i defines key management protocol (4-Way/PTK handshake, 2-Way/Group Key handshake) and optimizations for full IEEE 802.1X authentication (PMKSA caching, pre-authentication). IEEE 802.1X and EAP authentication is on similar level. All these are done using EAPOL packet (own ethertype; one for EAPOL and one for pre-authentication). This could be done in kernel, but I don't see much point in that and have thus implemented these in user space. wpa_supplicant includes the Supplicant part both for IEEE 802.1X and IEEE 802.11i key handshakes. hostapd includes the Authenticator part for the same functionality. Being able to keep authentication and key management separated from the data encryption. There needs to be an interface for configuring and getting event information. I would say this can be considered as separate design area. Currently, hostapd and wpa_supplicant are using combination of ioctls (WE and private, depending on the driver) for user space -> kernel configuration (e.g., encryption keys), wireless events (netlink) for getting event information (association/encryption error/etc.), network interfaces with or without IEEE 802.11 headers (e.g., hostapd includes IEEE 802.11 headers for management frames in a separate interface and wpa_supplicant uses just Ethernet header and normal data interface to get the two special ethertypes). This communication interface can be replaced with something different, if desired, without affecting the other parts of the implementation (the encryption of data frames itself or the authentication/key management protocols). -- Jouni Malinen PGP id EFC895FA |
From: Vladimir K. <vk...@ma...> - 2004-09-02 20:25:47
|
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=20 Is this stack the main one that is going to be used? I.e. if I am working o= n=20 driver for next generation .11 card - should I try to use it, request/submi= tt=20 missing features etc.? Or should I use wireless extensions? |
From: Jeff G. <jg...@po...> - 2004-09-02 20:34:12
|
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 |
From: Vladimir K. <vk...@ma...> - 2004-09-03 18:04:41
|
Is anyone working on this stack? I asked Dave, he is hot working on it. Or is this code dead? On Thursday 02 September 2004 23:33, Jeff Garzik wrote: JG> Vladimir Kondratiev wrote: JG> > Jeff, JG> > JG> > On Tuesday 31 August 2004 21:21, Jeff Garzik wrote: JG> > JG> Denis Vlasenko wrote: JG> > JG> > I think 'senior' network guys are in position to decide upon which JG> > JG> > of currently available 802.11 stacks we should continue to work. JG> > JG> > (Atheros has one, said to be derived from BSD, is there any others?) JG> > JG> JG> > JG> JG> > JG> Already have. Start with the code in wireless-2.6 -- HostAP -- and use JG> > JG> DaveM's 802.11 stack template as a model for actually integrating 802.11 JG> > JG> very tightly with the rest of the net stack. JG> > JG> JG> > JG> JG> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8 JG> > 0211.tar.bz2 JG> > JG> > Is this stack the main one that is going to be used? I.e. if I am working on JG> > driver for next generation .11 card - should I try to use it, request/submitt JG> > missing features etc.? Or should I use wireless extensions? JG> JG> DaveM's code is a template for how a wireless stack would look when JG> properly and fully integrated into the net core. JG> JG> Although JeanT and I disagree about this, I am less interested in JG> backwards compatibility than I am about making wireless a "first class JG> citizen" in the kernel. As I have proven with kcompat JG> (http://sf.net/projects/gkernel/) you can be backwards compatible while JG> still evolving the current kernel driver API to meet current design needs. JG> JG> Jeff JG> JG> JG> JG> |
From: Jeff G. <jg...@po...> - 2004-09-03 20:30:18
|
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 |
From: Sam L. <sa...@er...> - 2004-09-06 18:14:28
|
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 acx111 hardware is a bit like > Atheros and possibly prism54 "softmac": it handles mostly low-level > rx/tx stuff, leaving 802.11 stack implementation up to OS > (which is good. To have largish potentially buggy binary-only firmware > to cope with is a nightmare). > > I think what acx100 devel is working on can be best described as > "yet another 802.11 stack implementation". This is not ok. > > I think we definitely need generic 802.11 stack, with individual > drivers > providing only needed callbacks, just like it is done for wired eth > drivers. > > I think 'senior' network guys are in position to decide upon which > of currently available 802.11 stacks we should continue to work. > (Atheros has one, said to be derived from BSD, is there any others?) To correct this oft-repeated misinformation: "Atheros has one" is wrong. There is a freely available device-independent 802.11 protocol stack that is dual BSD/GPL licensed. The only relationship between this code and Atheros is that the madwifi project uses it to support Atheros hardware under Linux. Atheros holds no copyrights on any of the net80211 code. As to it being derived from BSD, that is correct but misleading. The 1st generation of this code was done for netbsd but the current code is very different and has been developed almost exclusively in Linux for over a year (though I'm now trying to find time to backport to FreeBSD). The net80211 code is actively used in netbsd to support 6+ drivers and a similar number in freebsd. There is a fairly complete implementation of the 802.11 protocols (fragmentation isn't there but will be soon) including 11g, WPA/11i, WME and WSM (coming soon). WPA/802.11i supplicant support using wpa_supplicant has been available for a while and a hostapd-based authenticator will hit CVS shortly. The management API for Linux is based on wireless extensions (WE is insufficient so like everyone else you'll find lots of private ioctls). I've suggested this code as a good starting point for a "generic 802.11 stack" but received only misinformed responses. Folks who are unaware of the work should take a look at it. Sam |
From: David S. M. <da...@da...> - 2004-09-07 01:26:11
|
On Mon, 6 Sep 2004 11:13:31 -0700 Sam Leffler <sa...@er...> wrote: > I've suggested this code as a good starting point for a "generic 802.11 > stack" but received only misinformed responses. 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 eater thing that's an ugly wart bolted onto the side of the driver API. |
From: Sam L. <sa...@er...> - 2004-09-07 04:29:26
|
On Monday 06 September 2004 06:23 pm, David S. Miller wrote: > On Mon, 6 Sep 2004 11:13:31 -0700 > > Sam Leffler <sa...@er...> wrote: > > I've suggested this code as a good starting point for a "generic 802.11 > > stack" but received only misinformed responses. > > 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 eater thing that's an ugly wart bolted onto the > side of the driver API. 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 stack right" and were going to do it that weekend. I waited but it seems the sum total result was the shell of code that Jeff referenced in a previous note. Perhaps you can point me at a description of what a "true network stack" means to you. I'm guessing this has to do with your wanting queues inserted at various places instead of direct handoffs. Regardless, I've never suggested the current code is suitable as-is but rather should be reshaped to suit the intended structure of the system. There is a lot of hard-earned experience in the code that is independent of coding style and operational infrastructure. Anyway, the point of my note was to correct a comment in the original posting and make folks aware that working code existed from which they could crib stuff. Good luck finding someone to reimplement eveything according to your wishes. Sam |
From: David S. M. <da...@da...> - 2004-09-07 06:50:57
|
On Mon, 6 Sep 2004 21:32:49 -0700 Sam Leffler <sa...@er...> wrote: > Actually, this is the first time you've said anything to me about this code. 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. > Perhaps you can point me at a description of what a "true network stack" means > to you. It means passing the 802.11 protocol packets into the networking just like any other type of packet, via netif_rx() or netif_receive_skb(). Creating an ETH_P_80211 protocol type and registering the stack via dev_add_pack() just like any other real protocol layer does. Then responses generated in that 802.11 stack need to feed packets back out to the network via the normal and usual methods of transmitting packets in the networking, namely dev_queue_xmit(). That is exactly what my shell protocol layer does, and it is exactly how a real 802.11 soft stack should be implemented and operate. |
From: greg c. <gr...@at...> - 2004-09-07 17:02:53
|
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 of the driver API. what's good for the goose, etc. My point is that there is ample precedent in the OS for common driver "assistance" subroutines that contain protocol knowledge or implement policy yet are not implemented in strict stack-like manner because it didn't make sense to do 'em that way. It seems to me that Sam's net80211 code is performing three essential functions: 1. encap/decap service for converting between 802.3 and 802.11 2. the MLME protocol (802.11 management messages and state keeping) 3. interface to upper layer ioctl stuff, particularly user-land crypto supplicants and authenticators in addition to the usual group of tools. The MLME protocol works as a stack already since it really does implement a protocol. The encap/decap could be implemented stack-like instead of eth_type_trans-like, but it seems very suboptimal to do it another way. The ioctl interfaces are a wart on the side of the driver API anyway, but let's not have an argument about that since it is a design feature of the OS inherited from unix. The complaint seems to be mainly about the encap/decap procedures which are implemented more as driver helper functions. If somebody wants to rewrite them as a stack, then go for it. I'll be interested in seeing whether or not good methods can be found for exporting driver-local information (e.g. the mac address of the AP, or the tx PHY rate needed to calculate the duration field value, or whether or not to do mac tx fragmentation, etc) up the stack without creating a pile of spaghetti to rival Microsoft's failed "native 802.11" project. I've thought about this problem and don't think there is a good answer if a layered approach to protocol implementation stipulates that each layer be self-contained. The 802.11 situation requires more data-sharing between layers than is conducive to a strict layering approach. I suspect that what's needed is a data structure tailored to wireless which can be shared between layers and common across devices. Perhaps it could be an extention to dev (wdev?) that captures the necessary sharing. But the problems don't stop there. Think for a moment about where power-save should be implemented - which layer? cheers, g Sam Leffler wrote: > On Monday 06 September 2004 06:23 pm, David S. Miller wrote: > >>On Mon, 6 Sep 2004 11:13:31 -0700 >> >>Sam Leffler <sa...@er...> wrote: >> >>>I've suggested this code as a good starting point for a "generic 802.11 >>>stack" but received only misinformed responses. >> >>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 eater thing that's an ugly wart bolted onto the >>side of the driver API. > > > 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 stack right" and were going to > do it that weekend. I waited but it seems the sum total result was the shell > of code that Jeff referenced in a previous note. > > Perhaps you can point me at a description of what a "true network stack" means > to you. I'm guessing this has to do with your wanting queues inserted at > various places instead of direct handoffs. Regardless, I've never suggested > the current code is suitable as-is but rather should be reshaped to suit the > intended structure of the system. There is a lot of hard-earned experience > in the code that is independent of coding style and operational > infrastructure. > > Anyway, the point of my note was to correct a comment in the original posting > and make folks aware that working code existed from which they could crib > stuff. Good luck finding someone to reimplement eveything according to your > wishes. > > Sam |
From: David S. M. <da...@da...> - 2004-09-07 17:15:38
|
On Tue, 07 Sep 2004 10:03:41 -0700 greg chesson <gr...@at...> wrote: > What about eth_type_trans()? 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, and surprise surprise my skeleton 802.11 stack code in fact does exactly this. > I've thought about this problem and don't think there is a good answer > if a layered approach to protocol implementation stipulates that each layer > be self-contained. In my 802.11 stack the 802.11 information structure can be found given a generic device pointer. All the wireless info can be retrieved from that, and you can use it to call the wireless stack routines if you wish as well. This is no different than how we keep ipv4 information hooked onto the generic device structure and walk between these various entities in the ipv4 and generic networking code. Please read my skeletal stack code, it is exactly how I truly believe something like this should be architected. It's all the base layout stuff that's important, the rest are details that will fit in cleanly and readily once you have a solid and firm foundation. |
From: Vladimir K. <vk...@ma...> - 2004-09-06 18:58:34
|
Sam, could you please provide URL where this code is hosted? I know it only as p= art=20 of madwifi.=20 Vladimir SL> I've suggested this code as a good starting point for a "generic 802.11 SL> stack" but received only misinformed responses. Folks who are unaware SL> of the work should take a look at it. SL> SL> Sam |
From: Sam L. <sa...@er...> - 2004-09-06 19:31:35
|
On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote: > Sam, > > 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 currently available only via cvs (but there's a web interface that you can reach through the above url). Sam |
From: Vladimir K. <vk...@ma...> - 2004-09-06 20:09:48
|
I know about madwifi. I wondering whether there is URL for net80211, or it= =20 exist only as part of madwifi. Thanks, Vladimir On Monday 06 September 2004 22:30, Sam Leffler wrote: SL> On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote: SL> SL> > Sam, SL> > SL> > could you please provide URL where this code is hosted? I know it only SL> > as part SL> > of madwifi. SL> SL> The madwifi project is hosted at sourceforge SL> http;//sourceforge.net/projects/madwifi. Source code is currently SL> available only via cvs (but there's a web interface that you can reach SL> through the above url). SL> SL> Sam |
From: Sam L. <sa...@er...> - 2004-09-06 23:00:16
|
On Monday 06 September 2004 01:09 pm, Vladimir Kondratiev wrote: > I know about madwifi. I wondering whether there is URL for net80211, or it > exist only as part of madwifi. It only exists as part of other systems (madwifi, netbsd, freebsd, etc.) Sam |
From: greg c. <gr...@at...> - 2004-09-07 18:13:38
|
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 <gr...@at...> wrote: > > >>What about eth_type_trans()? > > > 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, and surprise surprise my skeleton 802.11 > stack code in fact does exactly this. > > >>I've thought about this problem and don't think there is a good answer >>if a layered approach to protocol implementation stipulates that each layer >>be self-contained. > > > In my 802.11 stack the 802.11 information structure can be > found given a generic device pointer. All the wireless info > can be retrieved from that, and you can use it to call the > wireless stack routines if you wish as well. > > This is no different than how we keep ipv4 information hooked > onto the generic device structure and walk between these various > entities in the ipv4 and generic networking code. > > Please read my skeletal stack code, it is exactly how I truly > believe something like this should be architected. It's all > the base layout stuff that's important, the rest are details > that will fit in cleanly and readily once you have a solid > and firm foundation. > |
From: David S. M. <da...@da...> - 2004-09-07 18:22:14
|
On Tue, 07 Sep 2004 11:14:17 -0700 greg chesson <gr...@at...> wrote: > I certainly agree with you about getting the base design right. > Where are these bits you refer to? See earlier in this very thread you are replying to: http://marc.theaimsgroup.com/?l=linux-netdev&m=109415745726088&w=2 :-) |
From: jamal <ha...@cy...> - 2004-09-08 07:40:02
|
On Tue, 2004-09-07 at 13:10, David S. Miller wrote: > On Tue, 07 Sep 2004 10:03:41 -0700 > greg chesson <gr...@at...> wrote: > > > What about eth_type_trans()? > > 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, and surprise surprise my skeleton 802.11 > stack code in fact does exactly this. 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). .. er, at the driver level. So this is not "a gross input packet hooked eater thing that's an ugly wart bolted onto the side of the driver API.";-> cheers, jamal |
From: greg c. <gr...@at...> - 2004-09-08 16:02:15
|
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. Everyone sees the same potential for unification of wireless drivers. 2. It's harder to do than it first appears because the complete transformation from .3 to .11 cannot be done in isolation from the driver(s) and there are monkey wrenches that get tossed in from crypto, interaction between crypto and fragementation, power-save, observing txoplimits, and other things that tend to cross architecture lines that would otherwise be nice and clean. 3. I personally don't have religion about whether a service that transforms headers is implemented as a stack or implemented as a side call. I think that a variety of factors are worth considering. In this particular case (header transformation), I believe a side call "helper function" is appropriate and has less overhead than the full protocol stack mechanism. But it's pointless to argue about it without measurements. 4. David's skeleton code is quite interesting and a good start. You won't know its usefulness until someone tries to implement a real driver. g jamal wrote: > On Tue, 2004-09-07 at 13:10, David S. Miller wrote: > >>On Tue, 07 Sep 2004 10:03:41 -0700 >>greg chesson <gr...@at...> wrote: >> >> >>>What about eth_type_trans()? >> >>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, and surprise surprise my skeleton 802.11 >>stack code in fact does exactly this. > > > 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). > .. er, at the driver level. So this is not "a gross input packet > hooked eater thing that's an ugly wart bolted onto the > side of the driver API.";-> > > cheers, > jamal > > > |
From: Vladimir K. <vk...@ma...> - 2004-09-08 19:52:12
|
Greg, you missed one important point. Besides data packets, that every driver now= =20 convert .11<->.3 using almost the same code, there is whole story of=20 management. Many modern cards are "softmac" and do all management on host. = I=20 see no point for every driver to implement its own scanning and association= =2E=20 It is simply waste of resources. To make step forward, I suggest the following: 1. Dave's code is at least year old. someone need to start maintain it,=20 starting with update for current kernel infrastructure. Get it compile and= =20 load for 2.6.9, for example. 2. To debug stack, you don't need real driver. I can write dummy .11 driver= =20 that will silently discard all Tx, and will provide some way for user level= =20 tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it= =20 is sufficient. Later, when it will come to timing, performance etc, it will= =20 be easy to strip some real driver. This may be king of "proof of concept". Vladimir On Wednesday 08 September 2004 19:02, greg chesson wrote: gc> You guys are too serious and, I believe, missed the real points. gc> gc> 1. There is a need in the OS for a "service" to convert between gc> .11 and .3 packet formats. It should be designed for gc> hw-independence. gc> Everyone sees the same potential for unification gc> of wireless drivers. gc> gc> 2. It's harder to do than it first appears because the complete gc> transformation from .3 to .11 cannot be done in isolation gc> from the driver(s) and there are monkey wrenches that get gc> tossed in from crypto, interaction between crypto and fragementation, gc> power-save, observing txoplimits, and other thin= gs that tend gc> to cross architecture lines that would otherwise be ni= ce and clean. gc> gc> 3. I personally don't have religion about whether a service gc> that transforms headers is implemented as a stack or implemented gc> as a side call. I think that a variety of factors are worth gc> considering. gc> In this particular case (header transformation), I believe a side call gc> "helper function" is appropriate and has less overhead than the full gc> protocol stack mechanism. But it's pointless to argue about it gc> without gc> measurements. gc> gc> 4. David's skeleton code is quite interesting and a good start. gc> You won't know its usefulness until someone tries to implement gc> a real driver. gc> gc> g gc> gc> gc> gc> jamal wrote: gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote: gc> > gc> >>On Tue, 07 Sep 2004 10:03:41 -0700 gc> >>greg chesson <gr...@at...> wrote: gc> >> gc> >> gc> >>>What about eth_type_trans()? gc> >> gc> >>It determines the protocol type from the ethernet header gc> >>fields. It is a simple shorthand header field fetcher, gc> >>not a protocol stack. gc> >> gc> >>You would need a eth80211_type_trans() for wireless gc> >>drivers too, and surprise surprise my skeleton 802.11 gc> >>stack code in fact does exactly this. gc> > gc> > gc> > Or as Andi has been suggesting for sometime, not invoke it all ;-> gc> > This is possible if the DMA descriptor already has all the info gc> > needed (quiet a few modern hardware can be programmed to do this). gc> > .. er, at the driver level. So this is not "a gross input packet gc> > hooked eater thing that's an ugly wart bolted onto the gc> > side of the driver API.";-> gc> > gc> > cheers, gc> > jamal gc> > gc> > gc> > gc> gc> gc> gc> |