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.

The list wasn't complete, it was the things that need (from my POV) to
be resolved first only. There are more issues - some of them are known
to me, including this one, but I have them stored mostly as comments at
corresponding places in my development tree. I will try to extract them
into some nice todo list accessible to others.

>  - port IPW drivers instead of just moving everything around,
>    get rid of old code completely

:-)

>  - 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 */

> and finally
>  - fix tabs vs spaces all over the place ;)
> 
> I also have a couple of questions:
> 
> It seems that all packets are tried to decrypt with all possible
> algorithms, or is that just my misunderstanding of the code? Wouldn't it
> be possible to know what to expect and only pass it through those
> functions that are needed?

The frames really goes through all of decryption functions but they are
not tried to decrypt, the functions return at they beginning. This
probably can be optimized. And many other parts of the code need
optimization too.

> 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 may be related to your item about reducing the number of
> interfaces, but why do you have vlan interfaces explicitly? Shouldn't
> the generic vlan code be able to handle this?

It's not vlan. Some devices are capable to associate to multiple APs and
you need to present this to userspace by more interfaces. The same with
WDS links.

Thanks for your comments,

-- 
Jiri Benc
SUSE Labs
-
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

Reply via email to