netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: netdev@vger.kernel.org
Cc: Jean Tourrilhes <jt@hpl.hp.com>
Subject: proposal for new wireless configuration API
Date: Tue, 15 Aug 2006 17:28:48 +0200	[thread overview]
Message-ID: <1155655728.17742.30.camel@ux156> (raw)

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

             reply	other threads:[~2006-08-15 15:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-15 15:28 Johannes Berg [this message]
2006-08-15 16:14 ` proposal for new wireless configuration API Luis R. Rodriguez
2006-08-16  7:26   ` Johannes Berg
2006-08-15 16:29 ` Dan Williams
2006-08-15 16:38   ` Michael Buesch
2006-08-15 18:14     ` Dan Williams
2006-08-15 19:13       ` Michael Buesch
2006-08-15 19:27         ` Simon Barber
2006-08-15 19:35           ` Michael Buesch
2006-08-15 20:06             ` Dan Williams
2006-08-15 19:59         ` Dan Williams
2006-08-16  7:14           ` Johannes Berg
2006-08-17 19:39         ` Jean Tourrilhes
2006-08-17 21:24           ` Michael Buesch
2006-08-17 23:29     ` Ulrich Kunitz
2006-08-18  7:12       ` Johannes Berg
2006-08-18 15:00         ` John W. Linville
2006-08-18 21:29         ` Ulrich Kunitz
2006-08-18 22:02           ` Michael Buesch
2006-08-21  7:31             ` Johannes Berg
2006-08-16  6:51   ` Johannes Berg
2006-08-16 18:02     ` Simon Barber
2006-08-17  7:19       ` Johannes Berg
2006-08-17 16:42         ` Simon Barber
2006-08-17 23:23           ` Ulrich Kunitz
2006-08-18  7:01           ` Johannes Berg
2006-08-18 16:45             ` Simon Barber
2006-08-21  6:45               ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1155655728.17742.30.camel@ux156 \
    --to=johannes@sipsolutions.net \
    --cc=jt@hpl.hp.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).