LWN: Comments on "The final wireless extension?"

"The wireless extensions, it seems, may be extended no more"

slamb — Fri, 13 Oct 2006 02:26:29 +0000

It's good writing, but I don't think it's actually true. Couldn't the existing version number be frozen
at 20 and a "real" version number added as another ioctl()? The behavior on unknown ioctl()s is
well-defined, so there'd be a reliable way to know if the API was extended in a different way than
originally planned for version 21.

This would make the check-for-21-or-higher tools think it's 20, yet newly written tools know
it's something else. They could even negotiate a version to use.

it's an ugly solution and perhaps not worthwhile, but it's possible.

Incremental, or all-at-once migration?

johill — Fri, 06 Oct 2006 08:52:01 +0000

Well, first of all, drivers are expected to implement cfg80211 which is (I hope!) a clearly defined interface using structs and callbacks instead of the SIOCxIWxxx madness.

Secondly, I just posted a patch yesterday (though netdev rejected it) to make it possible to use WE as a userspace interface to cfg80211, and make it possible to convert drivers one by one (even one configuration call at a time!).

Yes, it is now necessary to convert each driver, however, the semantics are hopefully much clearer defined. It was never clear, for example, what SIOCGIWAP was supposed to return because it was overloaded for two purposes, so drivers did it differently. cfg80211 separates it out into two calls, and tries to do a best-effort for WE-userspace.

Humor

jstAusr — Fri, 06 Oct 2006 01:05:01 +0000

Seconded. I'm just a dumb user yet I understand, in general, most everything Jon writes. How does he do that?

Humor

simonl — Thu, 05 Oct 2006 21:47:12 +0000

> The wireless extensions, it seems, may be extended no more.

Jon, you are a brilliant writer.

The final wireless extension?

NAR — Thu, 05 Oct 2006 16:11:32 +0000

If those tools see a wireless extensions version greater than 20, they expect to use the new ESSID string format; if that change is backed out, those tools will break.

Maybe next time these tools will use some kind of 'capability-synchronizing' handshake instead of simply checking the version...

Bye,NAR

The final wireless extension?

pizza — Thu, 05 Oct 2006 14:02:53 +0000

It's not just WirelessTools, Jean has also been coordinating this API change with nearly every application and driver that speaks WE. He got all affected parties on-board.

The sad thing is that his libwext stuff transparently handles all of this stuff, and if more people used it, this wouldn't have been a problem..

This problem is going to bite linux-wireless many more times in the future, given how fast the wireless world changes. There's going to be a LOT of backwards-compatiblity cruft in the kernel as the 802.11 standards continue to evolve -- it's not just "API" changes, but behaivoral changes too, and that's where the real pain lies.

Incremental, or all-at-once migration?

pizza — Thu, 05 Oct 2006 13:57:30 +0000

So does every 802.11 driver now have to implement nl80211 independently, and in addition to WE?

And will this result in the same "every implementation is slightly different and buggy" mess that WE had for so long?

nl80211 is not tied to d80211

johill — Thu, 05 Oct 2006 09:59:13 +0000

That's actually a common misconception, but is just not true. Any card can register a cfg80211 operations structure and be configured with nl80211 (and WE through it too soon!). In fact, I wrote cfg80211/nl80211 very much with that in mind.