On Wed, Jan 04, 2006 at 01:35:08PM +0100, Jiri Benc wrote: > On Tue, 03 Jan 2006 18:06:30 +0100, Johannes Berg wrote: > > How about > > - get rid of all the embedded algorithms (AES, Michael, RC4, > > CRC) and use the crypto layer from the kernel > > Definitely.
Yes, that is also on my to-do list. The versions in Host AP driver (and well, now in net/ieee80211) are of newer design. With the possibility to rely on the kernel having crypto API, these should indeed be used. I haven't yet looked into whether ipw drivers have changed the crypto code enough to handle the case of hardware acceleration for all/some frames. This was missing from Host AP code due for TKIP/CCMP. > > - split out frame crypto stuff into modules like ieee80211 does > > (or maybe even use those?) > > Would be nice. See also a comment in ieee80211.c: > > /* TODO: implement register/unregister functions for adding TX/RX handlers > * into ordered list */ Yes, this is indeed the goal here. Lots of the functionality could be moved into kernel modules that are loaded only if needed. That would speed up TX/RX path when smaller number of handlers are needed. > > What's with CONFIG_OAP_LEDS_WLAN? Shouldn't that LED handling function > > be a pointer that can be assigned to whatever one wants, and you could > > then get rid of IEEE80211_LEDS etc? > > LED handling seems strange. It probably depends on some other stuff not > released by Devicescape, I would suspect something responsible for > handling LEDs on their AP boxes or so. This is a very old interface for a customer. I don't think it was ever really used at Devicescape and I certainly don't see much need for it in the current version. In other words, it could just be removed. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
