On Fri, 2011-10-28 at 09:33 -0700, Ben Greear wrote: > >> * Allow configuring the mcs (/n) rates available. > >> * Allow configuration of MAX-A-MSDU > >> * Allow configuration of A-MPDU factor& density. > >> > >> Users can only remove existing rates. The MSDU and MPDU > >> values can be set to any value allowed by the 802.11n > >> specification. > > > > That can't work -- the device might not support it. > > The device would always support removing rates, right? No. As I pointed out in another email, you need to think beyond mac80211. > As for the MSDU and MPDU stuff, I would need to add capabilities > flags and then enable each driver as they are tested? No. Neither of these can ever be increased so it's not that simple. And making it smaller is always possible since it's just advertising. Presumably you do understand the reasons for this advertising/these restrictions? > > I also don't really like the way you pass in some binary "mask" when > > it's not really a binary masking operation. > > I found the mask to work very well. It's easy enough to > deal with in user-space, and easily allows us to add override features > (the additional bits to support the MPDU stuff once the > HT rates logic was in is a very small bit of code). > > Otherwise, I'll need to add new netlink commands for each new > feature. That is going to bloat hostapd as well as the > kernel. I'm not sure it'll bloat it, but I can live with the binary struct. It seems a bit ugly to me but I think it's acceptable. However, you should document more clearly what struct it is and how it is defined to work. You're also relying on userspace to not do stupid things (otherwise your code reads memory out of bounds), this would help: > /* add attributes here, update the policy in nl80211.c */ Anyway, I'm out of breath. I think this is simply bad implementation & execution of your ideas. These are somewhat interesting features and I'm willing to accommodate even some of the more esoteric features that most people will never use, but I'm quite annoyed by how much of your patches I end up doing myself through review. Please focus more on the quality of your patches in "details" like security, API issues, non-mac80211 drivers and even simply logic like the A-MSDU thing I just pointed out. I'm spending a disproportionate amount of time reviewing your patches over and over again with every patchset and am no longer willing to do that. Obviously we'll still have to discuss things like whether it should be a connection or interface parameter -- but I shouldn't have to point out trivial security issues -- you should be focusing more on these things while writing the code, not after the fact where it's much harder. E.g. never ever use nla_data() without validating nla_len() in some way, it seems to me that should be completely obvious. > >> @@ -114,6 +115,19 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie, > >> if (ht_info_ie[1]< sizeof(struct ieee80211_ht_info)) > >> return; > >> > >> + memcpy(&ht_cap,&sband->ht_cap, sizeof(ht_cap)); > >> + /* > >> + * This is for an association attempt, and we must > >> + * advert at least the first 8 rates, even if we > >> + * will later force the rate control to a lower rate. > >> + */ > >> + ieee80211_apply_htcap_overrides(sdata,&ht_cap, 8); > > > > Yuck, why, why hard-code 8, etc. > > I can make a define that involves MCS7. I don't think I understand then why MCSs 0-7 must be supported? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
