On Fri, 2013-01-18 at 11:18 +0530, Vasanthakumar Thiagarajan wrote: > + * @NL80211_ATTR_ACL_POLICY: ACL policy, see &enum nl80211_acl_policy_attr. > + * > + * @NL80211_ATTR_MAC_ADDRS: Array of nested MAC addresses, used for > + * MAC ACL. Ok so one last (not a promise ;-) ) thing ... You basically completely back-pedalled from wanting to support white & blacklist at the same time to no longer even allowing that in the API. Should I really merge this? Who says you're not going to return in a couple of weeks and want that then, making the API very strange? Right now, you have it structured like this: POLICY=u8 value, ADDRS=[1=addr1, 2=addr2, ...] (= indicates attribute type/value, [] indicates nesting) I think it might be smarter to do ACL=[TYPE=addr1|addr2|..., TYPE=addr3|addr4|...] where "|" just indicates concatenation. I don't really strictly see a reason to have a new nested attribute for each MAC address, since they are each just 6 bytes long, for all I care they could be concatenated. But if you wanted nesting, that would make it look like this: ACL[TYPE=[1=addr1, 2=addr2, ...], TYPE=[1=addr3, 2=addr4, ...]] which is acceptable too, just requires more code to parse. Anyway, if you think that the dual list approach is dead indefinitely, I guess I can apply it. I'm just not sure I believe that ;-) 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
