[RFC] sysfs + configfs on 802.11 wireless drivers

[RFC] sysfs + configfs on 802.11 wireless drivers

[Luis R. Rodriguez]

Rebel fleet of wireless developers,

Here's some changes which I think our current wireless stacks could
use to assist cleaning up WEs, private ioctls, and provide userspace a
cleaner framework to interact with our wireless drivers.

Kernel level:

(1) Use the new *configfs* for all user-specific attributes
(2) Use *sysfs* read-only kobjects for device-specific attributes like
values which can be saved for suspend() and collected for resume().
IEEE 802.11 capabilities, features (for example radiotap), and what is
currently settable/gettable from private ioctl realm along with its
restrictions can also be exported via sysfs.
(3) On resume() talk to userspace via netlink to read our sysfs and configfs us

Userspace applications can then:

(1) Interact with configfs for configuring wireless devices, including
what used to be set by private ioctls
(2) Retrieve attributes saved from sysfs and set them onto configfs
after resume(). Sysfs will also tell us this card's capabilities,
features and private data along with their respective restrictions we
can work with so -- userspace can modify the available options which
can be gettable/settable.
(3) Respond to netlink communication from driver after resume() to set
data through configfs

---

I know we recently moved WE to netlink but I figured celebrating the
happy marriage of Mr. sysfs and Mrs. configfs on 2.6.16 by giving them
offspring would be nice and more appropriate. Here's an example
run-through of how this would work:

(1) A wireless device comes up and spits out device-specific default
settings on sysfs

(2) If a user wants to change essid, channel, power-save-mode (this is
not suspend()), rate, and so forth userspace writes the settings into
configfs, these would in turn get updated on sysfs by the driver.

(3) Should the device go into suspend() the driver can then update its
necessary attributes on sysfs required to recover from suspend() which
may not have been updated yet (whatever they may be)

(4) At resume() we could just have our driver read our sysfs
attributes and try to set all of them back exactly how they were
before but to reduce bloat on our drivers and since our state is
already exported we could just have userspace do it for us so... we
use netlink to communicate to userspace to go ahead and ask it to
resume() us. Advantages of this would be userspace would always
consistantly handle the assoc/desassoc and WPA in a consistent manner
and as mentioned above, driver bloatness killing.

(5) At resume() userspace reads sysfs and sets us back up through configfs

Comments are appreciated, if this is something that seems desirable I
can start cranking up some code.

  Luis

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Thursday 22 June 2006 05:12, Luis R. Rodriguez wrote:
> (3) On resume() talk to userspace via netlink to read our sysfs and
> configfs us
>
I think that's fairly overkill. I really do not like the idea of requiring any 
more userspace involvement in the suspend process than needed. At least for 
ADM8211, all the data needed to restore the card properly is already stored 
somewhere for userspace (iwconfig) to query, so I don't understand how this 
is suppose to reduce bloat. All the data that is needed should already be 
stored in the driver to support configuring the interface before taking the 
interface up.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Greg KH]

On Thu, Jun 22, 2006 at 08:12:24AM -0400, Luis R. Rodriguez wrote:
> I know we recently moved WE to netlink but I figured celebrating the
> happy marriage of Mr. sysfs and Mrs. configfs on 2.6.16 by giving them
> offspring would be nice and more appropriate.

What, right after deciding one thing, you want to switch it all over to
something completly different?  How about giving netlink a chance and
wait to see how well (or not) that works out, so that you will have more
insight and history into any problems that you had so as to best address
them in the future.

thanks,

greg k-h

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Dan Williams]

On Thu, 2006-06-22 at 08:12 -0400, Luis R. Rodriguez wrote:
> (4) At resume() we could just have our driver read our sysfs
> attributes and try to set all of them back exactly how they were
> before but to reduce bloat on our drivers and since our state is
> already exported we could just have userspace do it for us so... we
> use netlink to communicate to userspace to go ahead and ask it to
> resume() us. Advantages of this would be userspace would always
> consistantly handle the assoc/desassoc and WPA in a consistent manner
> and as mentioned above, driver bloatness killing.

I think having the driver try to set all its state back is pretty much
useless in a large number of cases.  While definitely useful for some
cases, consider:

a) suspend, drive to work, resume
b) WPA-related stuff, which takes much more than simply setting SSID and
encryption key back on the card

Neither of these instances allows the driver to just stick its fingers
in its ears, hum loudly, and pretend nothing happened between suspend
and resume.  Essentially, drivers would be doing all this work for
unencrypted and WEP cases, and then only those cases where the machine
hasn't physically moved.

Our effort is probably better spent elsewhere, especially since many
popular userspace tools already handle resume for us just fine.  More
useful to have drivers just come back from resume in an initialized
state similar to system boot.

Dan

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[John W. Linville]

On Fri, Jun 23, 2006 at 07:50:47AM -0400, Dan Williams wrote:

> Our effort is probably better spent elsewhere, especially since many
> popular userspace tools already handle resume for us just fine.  More
> useful to have drivers just come back from resume in an initialized
> state similar to system boot.

I think Dan makes a lot of sense here.  Does anyone disagree?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Luis R. Rodriguez]

On 6/23/06, John W. Linville <linville@tuxdriver.com> wrote:
> On Fri, Jun 23, 2006 at 07:50:47AM -0400, Dan Williams wrote:
>
> > Our effort is probably better spent elsewhere, especially since many
> > popular userspace tools already handle resume for us just fine.  More
> > useful to have drivers just come back from resume in an initialized
> > state similar to system boot.
>
> I think Dan makes a lot of sense here.  Does anyone disagree?

How would we handle resume() when using WPA, for example? Dan are you
suggesting we just bring up the driver clean and expect userspace to
have handled recovery from anything we were doing? This is important.

Or should we just expect the driver to re-set all settings again and
expect wpa_supplicant to pick up well where it left off? If sysfs will
get cleared after resume then there is no point in using it, but if
its stateful after suspend then this is where I suspected
wpa_supplicant could make use of sysfs. Perhaps there is a better way
-- what I suggested was just an idea while we discussed resume/suspend
in another thread. The reason I started a new thread was I figured
configfs/sysfs could be used for other things as well.

  Luis

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Dan Williams]

On Fri, 2006-06-23 at 10:20 -0400, Luis R. Rodriguez wrote:
> On 6/23/06, John W. Linville <linville@tuxdriver.com> wrote:
> > On Fri, Jun 23, 2006 at 07:50:47AM -0400, Dan Williams wrote:
> >
> > > Our effort is probably better spent elsewhere, especially since many
> > > popular userspace tools already handle resume for us just fine.  More
> > > useful to have drivers just come back from resume in an initialized
> > > state similar to system boot.
> >
> > I think Dan makes a lot of sense here.  Does anyone disagree?
> 
> How would we handle resume() when using WPA, for example? Dan are you
> suggesting we just bring up the driver clean and expect userspace to
> have handled recovery from anything we were doing? This is important.

Well, for WPA you pretty much need a tool like wpa_supplicant to handle
connections for you, otherwise there wouldn't be a reason for
wpa_supplicant to exist.  I don't think we really want a bunch of code
in the driver to handle the reconnect cases, because this is exactly
what wpa_supplicant already does and does well.

I'm suggesting that instead of trying to stuff more logic in the drivers
to handle reconnect on resume, that the drivers just come back from
resume in the same state as system boot.  They are initialized with
default values and default state.  They allow userspace tools that
already know about policy and security to configure them, as these tools
would do right after a system boot.  We can't assume that policy and
security are exactly the same as before sleep.

> Or should we just expect the driver to re-set all settings again and
> expect wpa_supplicant to pick up well where it left off? If sysfs will
> get cleared after resume then there is no point in using it, but if
> its stateful after suspend then this is where I suspected
> wpa_supplicant could make use of sysfs. Perhaps there is a better way
> -- what I suggested was just an idea while we discussed resume/suspend
> in another thread. The reason I started a new thread was I figured
> configfs/sysfs could be used for other things as well.

I don't know that you can really "pick up where it left off" in many
cases.  Again, the system can be moved, access points can go away, more
networks can appear, and WPA is just more complicated than WEP.  You
simply cannot expect a driver to return to its exact pre-sleep state
when using stuff like 802.1x/WPA[12] Enterprise.  What if your session
keys expired while you were sleeping, for example?

Besides, userspace tools like NetworkManager and wpa_supplicant are just
going to overwrite the config settings the driver restores anyway, since
you need to do another scan, check results, and set the connection back
up after accounting for stuff that may have changed.  Blindly attempting
to connect with all the old settings doesn't make much sense.

It's an optimization to have the driver restore settings, and it might
make things a second or three quicker in some cases, but in many other
cases it's completely useless to do this, possibly detrimental.  I don't
see the overall benefit right now.  We've got better things to do with
drivers at the moment.

Dan

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Jiri Benc]

On Thu, 22 Jun 2006 08:12:24 -0400, Luis R. Rodriguez wrote:
> Kernel level:
> 
> (1) Use the new *configfs* for all user-specific attributes
> (2) Use *sysfs* read-only kobjects for device-specific attributes like
> values which can be saved for suspend() and collected for resume().
> IEEE 802.11 capabilities, features (for example radiotap), and what is
> currently settable/gettable from private ioctl realm along with its
> restrictions can also be exported via sysfs.
> (3) On resume() talk to userspace via netlink to read our sysfs and configfs us

We need a new hostapd<->stack communication protocol. It definitely
cannot be configfs as we need asynchronous events; netlink seems to be
the best solution for this. Why should be a part of 802.11
userspace<->kernel communication done by netlink and part by
configfs/sysfs?

Second, all new network stuff is configured via netlink (or by ioctls,
but that doesn't count). Why should be 802.11 different?

I'd rather choose the way of extending current WE-netlink.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Luis R. Rodriguez]

On 6/23/06, Jiri Benc <jbenc@suse.cz> wrote:
> On Thu, 22 Jun 2006 08:12:24 -0400, Luis R. Rodriguez wrote:
> > Kernel level:
> >
> > (1) Use the new *configfs* for all user-specific attributes
> > (2) Use *sysfs* read-only kobjects for device-specific attributes like
> > values which can be saved for suspend() and collected for resume().
> > IEEE 802.11 capabilities, features (for example radiotap), and what is
> > currently settable/gettable from private ioctl realm along with its
> > restrictions can also be exported via sysfs.
> > (3) On resume() talk to userspace via netlink to read our sysfs and configfs us
>
> We need a new hostapd<->stack communication protocol. It definitely
> cannot be configfs as we need asynchronous events; netlink seems to be
> the best solution for this. Why should be a part of 802.11
> userspace<->kernel communication done by netlink and part by
> configfs/sysfs?

I can see how a hostapd<-->stack communication should be done via
netlink. I wasn't looking for everything to be done via configfs but
just its configuration which parallels perfectly with the design goals
of configfs. I still think it would ease tuning and configuration for
userspace while being nice if used sysfs to export capabilities. A
simple tree on the sysfs tree for the wireless device would list all
the details for the device. Configf's usefulness here may become more
evident if you think in terms of tuning for radiotap -- disalbe/enable
a few bits here and there.

> Second, all new network stuff is configured via netlink (or by ioctls,
> but that doesn't count). Why should be 802.11 different?
>
> I'd rather choose the way of extending current WE-netlink.

Forget about the resume() idea then, what I suggest is just the
configuration of the drivers to be done via configfs while the
driver's capabilities listed via sysfs. I think this would be useful.

  Luis

Re: [RFC] sysfs + configfs on 802.11 wireless drivers

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Fri, 2006-06-23 at 13:52 +0200, Jiri Benc wrote:

> I'd rather choose the way of extending current WE-netlink.

Nah, let's rewrite the blob of magic. Well, at least that's how I see it
right now ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]