Jiri,
> thanks a lot for your work on nl80211! New netlink interface is
> one of the most important things regarding 802.11 stack now.
Wait till you see my weekend patch series ;)
> Seems ineffective to me. Couldn't you require users of nl80211 to fill
> ieee80211_ptr field in all of their net_devices and use that to find out
> owner of the device? Then you don't need to call into every registered
> nl80211 user for each message.
What about non-d80211 fullmac drivers?
> Maybe put_priv would be better name for release_priv?
Yeah, ok.
> > [...]
> > +static int nl80211_drvpriv_by_ifidx(int ifindex, void **priv, struct
> > nl80211_driver **drv)
>
> Cut long lines, please.
Oops.
> > + /* unconditionally allow NL80211_CMD_GET_COMMANDS */
> > + skb_put(skb, 1);
>
> Shouldn't this be skb_put(msg, 1)? And in several other cases below too?
Woah, yes. I really should've tested that code as well.
> > +#define CHECK_CMD(ptr, cmd) \
> > + if (drv->ptr) { \
> > + skb_put(skb, 1); \
> > + *data++ = NL80211_CMD_##cmd; \
> > + }
>
> Could you move this define out of the function?
Sure. I'll also undef it afterwards.
> void nl80211_put_drvpriv(struct nl80211_driver *drv, void *priv)
> {
> if (drv->release_priv)
> drv->release_priv(priv);
> }
>
> And rename nl80211_drvpriv_by_ifidx to nl80211_get_drvpriv_by_ifidx, too.
Sure.
> Don't modify passed nl80211_driver. This way drivers cannot pass a static
> structure. Allocate you own structure and store a pointer to passed
> nl80211_driver there (or copy it into that your structure if you don't like
> dereferencing two pointers when calling callbacks).
Hmm, ok. I don't really like that too much either, but yeah, probably a
good idea. OTOH, if we make a copy anyway we could just as well require
drivers to make a copy, no? (And allocating just 12 bytes for three
pointers for the linked list feels stupid)
> > [...]
> > +void *nl80211hdr_put(struct sk_buff *skb, u32 pid, u32 seq, int flags, u8
> > cmd)
> > +{
> > + /* since there is no private header just add the generic one */
> > + return genlmsg_put(skb, pid, seq, nl80211_fam.id, 0,
> > + flags, cmd, nl80211_fam.version);
> > +}
> > +EXPORT_SYMBOL_GPL(nl80211hdr_put);
>
> Why is this exported? It should be used by nl80211msg_new only, shouldn't
> it?
No, for dumpit() callbacks you need this. Not sure if we'll ever have
any of those, but...
> Currently, master device is represented by a special net_device in d80211.
> It's not nice, "wiphy" device should be represented in some other way.
> Although I don't expect this would change (at least not in a foreseeable
> future) as it would require rewriting of great part of networking core, we
> should be prepared for it, so we would not be forced to change ABI or
> inventing workarounds if that eventually would happen.
>
> Also, d80211 allows some operations even without having any network
> interface present (of course, master interface is still present, but it's
> not nice to use its ifindex, especially in the light of previous paragraph).
>
> I propose this:
> - add NL80211_ATTR_WIPHY_INDEX attributte
We can do that at any time we want.
> - add wiphy_index field to nl80211_driver and require non-d80211 users to
> set it to -1
Woah, wait. Let's do it the other way around then, we give them a wiphy
index. That way, we have a central registry for it here in nl80211.
> - allow NL80211_ATTR_IFINDEX to be optional in some calls - the exact list
> of these calls is independent of any driver and can be hardcoded in
> nl80211
That's what I pretty much do already.
> - in such calls, specifying either NL80211_ATTR_IFINDEX or
> NL80211_ATTR_WIPHY_INDEX is enough; of course, when corresponding driver
> does not support wiphys (i.e. nl80211_driver.wiphy_index is -1), only
> NL80211_ATTR_IFINDEX can be specified
> - in other calls, NL80211_ATTR_WIPHY_INDEX should not be present
>
> Alternatively, you could introduce a flag to denote if NL80211_ATTR_IFINDEX
> field contains ifindex or wiphy index.
Ick, no flag. Let's just have two separate attributes, and on some calls
either one or both are valid.
johannes
-
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