Hi, So I've thought about this all day long... After writing this mail I'll go home and hope my inbox collects some feedback ;)
I've arrived at the following conclusions: * we want to use genetlink * we need an equivalent of the old commit() call, but without all the stupidity * we want to do packet injection and many other advanced features with it, and keep it extensible NB: I have some code, so don't start ;) Hence, I came up with the following system. Note that I don't use any private header for the netlink messages. - we implement a bunch of commands, for example NL80211_CMD_INJECT and _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()], _GETATTRGROUP, ... - we have a whole bunch of possible attributes: NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify) NL80211_ATTR_IFINDEX: index of interface to use (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure) NL80211_ATTR_ESSID, FRAGTHRESHOLD, CHANNEL,...: most of the old wext ioctls map to attributes now NL80211_ATTR_FRAME: frame to inject, or received mgmt frame - we use a few multicast groups: (a) one for management frames that are received (b) one for scan results as they come available (When, for example, someone requests scan results, they are simply multicast to the group+the requester, if they come available during operation they can also be multicast here) Note that I haven't mentioned commit(). NL80211_CMD_GETATTRGROUP returns a list of attributes that make sense to set with a single _SETATTR call and multiple attributes. an old sequence of iwconfig eth0 essid 'lalala' iwconfig eth0 channel 2 iwconfig eth0 commit would then be translated in the compat layer to a single _SETATTR message with the channel and essid attributes. Ultimately, we'll get rid of this, so a userspace tool using the netlink configuration would just tell the user via _GETATTRGROUP which attributes make sense to group together for optimal card behaviour. As for the inject command, it looks like on the current wmgmt# interface for d80211 has a bunch of implicit behaviour like looking into the transmitted frame to see what type it is etc. I'd like to get rid of it and stuff the information for that into ATTR_FLAGS instead. Oh and of course we'll have a structure somewhere that drivers and stacks register with the module that provides this netlink interface. That module will then also multiplex the commands to the drivers/stacks. I have that mostly figured out. Since it will be easy to tell if a specific driver/stack implements old-style wext or this new API we can allow drivers with both APIs to coexist for a while. I won't map the new API to the old wext one of course, but mapping the wext API to the new one we need anyway. Hence, we can change the wext code to call the new API if present and the old one otherwise (with a big fat printk), and then slowly migrate drivers over. Due to the reduced commit logic, it should become simpler too, even for old drivers. Anyway, comments appreciated. If we can agree on this general framework I'll start implementing the groundwork and some of the rest for d80211 soon. 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