Linux and wireless networking
Jeff went on to discuss a few of the challenges facing the Linux wireless implementation. This is, indeed, one area where some real progress is needed. Proprietary chipsets are just the beginning of the issues which must be dealt with - free software developers are actually beginning to catch up in that area. But before all the resulting drivers can be merged into a coherent whole, a few other things will have to be worked out.
One of those has to do with the 802.11 stack used by the kernel. As was discussed here last December, there is a fair amount of unhappiness with the in-kernel stack, which, among other things, has no "softmac" support, needed for adapters which do not perform MAC functions in hardware. A number of out-of-tree wireless stacks do provide that support, and there have been a lot of suggestions that one of those (usually the DeviceScape stack) be merged.
Those suggestions have been strongly resisted by the networking maintainers. They would rather see work go into fixing up the stack which is in the kernel now than replace it wholesale or - even worse - having two independent 802.11 stacks to maintain. Replacing the current stack would involve significant disruption in the networking subsystem, and would be hard to do without breaking the drivers which use the old stack. The two-stack solution, instead, would bloat the kernel and increase the amount of work required to maintain the networking subsystem into the future. So it is not surprising that there is a strong interest in evolving the current stack toward the desired functionality rather than bringing in a whole new implementation.
Still, the pressure to switch over to the DeviceScape stack appears to be growing. Jeff's posting seems to recognize this fact, and asks that, in the end, the developers at least pick a single stack which they can live with. And, says Jeff, regardless of which stack is chosen in the end:
Another issue has to do with the management interface for wireless adapters. Wired network adapters are relatively simple; set a few options on media access, give them an address, and they are ready to go. The wireless world is rather more complicated. To deal with the extra configuration required by wireless adapters, the "wireless extensions" interface - essentially a big set of ioctl() commands for querying and setting adapter parameters - was developed.
There seems to be a consensus that the wireless extensions have reached their expiration date, and need to be replaced with something else. Most developers would appear to favor a new (not yet specified) interface built on the netlink mechanism. User-space management code could then be rewritten to speak the new management protocol over netlink sockets.
This approach may seem strange, given the emphasis which has been placed on sysfs and the creation of scriptable, plain-text interfaces. Sysfs does seem like a poor match for wireless configuration, however. Wireless adapters have a large number of parameters, and it is often necessary to change several of them simultaneously. Sysfs, with its one-value-per-file rules, provides no means for this sort of atomic, multi-parameter update; a netlink interface could, instead, be designed with these needs in mind from the beginning.
Of the other issues mentioned, perhaps this one is the most significant: there is no wireless maintainer. The lack of a developer who is specifically interested in this area of networking and who will work to push it forward has clearly hurt. Fortunately, it appears that this era may be at an end: John Linville has stepped forward to take on this responsibility.
John has a fair amount of work ahead of him; quite a few developers have to
be brought together and made to agree on the way forward. To that end, a
wireless networking summit has been scheduled for
early April in Portland. If the attendees at that meeting (which looks to
include both kernel and user space developers) can produce a viable plan,
Linux may just lose its "superiority in the area of crappy wireless
support" before too long.
| Index entries for this article | |
|---|---|
| Kernel | Networking/Wireless |
| Kernel | Wireless extensions |
Posted Jan 12, 2006 3:31 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (8 responses)
Define the semantics of "write" to you sysfs attributes to be "store this value somewhere safe for later use".
Then have an attribute somewhere to which you can write "go".
This would require some locking so you don't get two apps writing to all those attributes at once, but that is hardly rocket-science.
Posted Jan 12, 2006 7:00 UTC (Thu)
by akumria (guest, #7773)
[Link] (4 responses)
Let's imagine that the program crashes in-between writing the new values and hitting the 'go' button.
Wouldn't that mean that I would not be able to determine the current values of various settings?
Posted Jan 12, 2006 7:09 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (2 responses)
As the new settings have not yet come into effect, there is no particular value in finding out what they are. But it would be useful to be able to revert any partial setting of these values.
So that attribute where you write 'go' to effect the new values: Also allow 'reset' to be written which reverts all the stored-for-later-use values to the currently active values.
Ofcourse this could be achived by simply reading each attribute and writing the value back again, but that it somewhat ugly.
There is a thing called 'configfs' in -mm which is meant to be able to provide this multiple-values-at-once thing, but when I considerred using it for something, it turned out to be too special purpose. The same thing can be achieved in sysfs with a bit of creativity, and I think it fits better there.
Posted Jan 12, 2006 13:58 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
I realize one of the key features of sysfs is that there's one value per file (try to avoid the mess that became /proc), but lack of atomic updates seems a rather fundamental limitation. What about writing multiple values to a write-only file?
echo "essid=bug;key=gazpacho" > /sys/class/net/eth1/config
Escaping would be required, of course, but that's easily solved.
I don't understand why a netlink socket would be an improvement... It requires parsing, like /proc, but is not user-configurable, like ioctls. It's the worst of both worlds!
Posted Jan 12, 2006 13:59 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 14, 2006 12:38 UTC (Sat)
by fergal (guest, #602)
[Link]
write(t, "rollback") or just closing the filehandle without writing "commit" would cause the new values to be discarded. Until the commit, everything else sees the old values. No danger from crashing programs, just kill them and start a new transaction. There are issues about concurrent updates to multiple parts of /sys but that'll be true in any system that provides atomic updates for multiple values.
Posted Jan 13, 2006 3:58 UTC (Fri)
by gregkh (subscriber, #8)
[Link] (1 responses)
But it's much easier to do with configfs, which is why it was created :)
Posted Jan 13, 2006 4:28 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
This doesn't seem to allow for reconfiguration. e.g. I want to change these three attributes atomically.
It also means that all the attributes appear under configfs for initial configuration, and may well need to appear in sysfs as well for monitoring/maintenance if they might change after initialisation. This is untidy.
In short, configfs seems to draw an unnatural distinction between initial configuration and ongoing maintenance, whereas I believe these should be indistinguishable.
The idea of using "mkdir" to create a new object is a nice one. It is a shame it cannot (does not) live directly in sysfs.
Posted Jan 19, 2006 8:51 UTC (Thu)
by georgm (subscriber, #19574)
[Link]
Yo have different folders for different configuration sets (one for each configuration) and a folder called current.
You change values in the configuration folders (e.g. one for home, one for work). If you finished, you do an "echo home > config_in_use" or something like that and the values of this folder are copied to current.
current is no symlink to solve the problem, if something crashes between changing and applying. So the current state could always be read from folder current.
Posted Jan 12, 2006 5:00 UTC (Thu)
by jhs (guest, #12429)
[Link]
Looks like a "necessary" was omitted.
Posted Jan 13, 2006 17:23 UTC (Fri)
by elanthis (guest, #6227)
[Link] (1 responses)
Really, what's the benefit of 'cat /sys/foo' over 'linux-config --get foo' ? Is it because C code has an easier time reading a value from a file than from another program's output? That's also easily solvable with a really simple C library liblinuxconfig or somesuch.
Using a special tool like linux-config could easily make atomic writes possible, assuming the actual netlink-based configuration protocol supports them, by simply allowing multiple keys to be set on the command line or piping some specially formatted lines to linux-config's stdin.
A separate tool would also allow much better error reports than sysfs by allowing errors to be sent to stderr.
Is sysfs really that great of an idea, or was it just another case of someone pushing something into the kernel without *really* thinking things through, a lot like how devfs is (now) recognized to be?
Posted Jan 14, 2006 12:05 UTC (Sat)
by alex (subscriber, #1355)
[Link]
Exactly that. cat is cat, it does what it says on the tin and is pretty stable and unlikly to break. Once you move away from text based keys then you have issues with is linux-config up to date with the kernel? Has the ABI changed? Is linking working so linux-config can find /lib/libconfig.so?
Now the debate as to if sysfs can neatly support atomic writes of groups is one to be had but I think a text based sysfs is very handy for the problem domain its aimed at.
Atomic, multi-parameter update is quite possible with sysfs. You just need a "go" button.Using sysfs for configuring wireless networking
This validates all those stored-for-later-use values and if they appear valid they all get update atomically.
Using sysfs for configuring wireless networking
A fair point.Using sysfs for configuring wireless networking
That's starting to sound fairly brutal, don't you think? The cure might be worse than the disease.Using sysfs for configuring wireless networking
If the size of that multi-value lump is bigger than a page, write() is not necessarily atomic either.Using sysfs for configuring wireless networking
Using sysfs for configuring wireless networking
t = open(">/sys/blah/transaction")
... # write lots of new values
write(t, "commit")
close(t)
> Atomic, multi-parameter update is quite possible with sysfs.Using sysfs for configuring wireless networking
> You just need a "go" button.
Configfs seems to be designed for initial configuration.
Using sysfs for configuring wireless networking
I like this idea, but I would change it a bit (to also solve the state thing mentioned in this thread:Using sysfs for configuring wireless networking
Small typo
Wireless adapters have a large number of parameters, and it is often to change several of them simultaneously.
Given that netlink sockets and specialized tools are already needed and will continue to be needed for many parts of the kernel, what is the benefit of having sysfs at all? All subsystems and modules could simply use a "generic" configuration protocol over netlink and standard tools for querying and setting those values could be part of the Linux userspace utilities.benefits of sysfs
"what's the benefit of 'cat /sys/foo' over 'linux-config --get foo'"
benefits of sysfs