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
