On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote: > And I strongly disagree with your disagrement ;-)
You're of course free to do that :) But let me explain. > I'm sorry to say it like this, but I hope my work will not be > impacted by vaporware. How many drivers are currently converted to > nl80211 ? None, I have to admit, of course. But I hope you realise that I can impossibly convert all drivers at once and all by myself. I merely set out a framework in which it is easy to add new features, new calls and make things behave. > The reason why those new features are good for you : > o They give you a template on how you could implement > those features in nl80211, saving you design time. Gack. I'm inclined to not even respond to this, but I am convinced that having all the unions and ill-defined semantics with one field having multiple meanings is in no way saving me design time because it's part of the problem I intend to completely avoid. > o The goal is to replace private ioctls (driver > specific) with standard ioctls. So, in other words, they actually > *reduce* the historic baggage and make it easier to wrap around those > functions if you want (I won't expect you to wrap around *every* WE). Actually, trust me, you will. Once drivers can no longer handle WEs by themselves because it's done centrally and over a shim layer in cfg80211, you will. > Personally, I still have not seen the point of nl80211, as the > full Wireless Extension is already available over NetLink (have you > tried it ?). Actually, no. But that's beside the point anyway. Actually, I think that publishing WE over netlink was a mistake. See, my gripes with WE aren't how the interface works. I could live with an ioctl based interface forever, we have many of those and that's not really a problem. The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. There are too many special cases. Setting an ESSID to all-zeroes to disable something (or was it all-ones to disable??) might have seemed like a good idea 10 years ago, but I certainly think that putting this implicit behaviour into a modern interface is just asking for the kind of trouble that WE has. > But, I shut up my big mouth, and let you work freely on > it, as a mark of respect for your work and intentions, and also > because something good may come out of it. :) > Personally, I though that the plan that was more or less the > consensus that the "new API" would be targeted mostly at the > DeviceScape stack, as it seems difficult to offer the full feature set > of that stack through WE. So, I would have expected the development of > the "new API" to be somewhat in sync with the integration of the > DeviceScape stack. Not at all. I plan to support all drivers over nl80211, even those that make no use of d80211. In fact, my current plan is to convert all drivers to nl80211 and put WE as a shim layer. Yes, that'll rip out a good part of your code, sorry about that. > And if you look closely, you will realise the other features > are also good for you ;-) Not really. More ioctls aren't good. Even if they replace private ones. Private ones were never really guaranteed anyway, so all the private ones that generically make sense (and shouldn't just be in debugfs instead...) shall be in nl80211 as well. johannes - 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
