On 6/23/06, Jiri Benc <[EMAIL PROTECTED]> 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
-
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
