On Thursday 31 August 2006 19:12, Jean Tourrilhes wrote: > On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote: > > On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: > > > o modulation > > > o long/short retry > > > o relative power saving. > > > > I strongly disagree to these. > > And I strongly disagree with your disagrement ;-) > > > What's the point of adding more ioctls that we'll be implementing them > > as wrappers around nl80211? Right now, those new ioctls/options aren't > > implemented in *any* driver at all so they're completely useless, and > > just add more to the pile of historic baggage we end up carrying around. > > If we add these to mainline now, it's another thing we'll have to carry > > for a long time even though it currently has no users... > > 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 ? > I hope you realised that we are all trying to make 802.11 > support progress, each through our own ways. And that all those > efforts are not conflicting with each other.
Yes. Why don't all people pull at the same rope end? > 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. > 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). I can't see how adding API reduces historic baggage. I don't think it's possible to reduce something by adding stuff to it. > Personally, I still have not seen the point of nl80211, as the > full Wireless Extension is already available over NetLink (have you > tried it ?). 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. Wireless Extensions are _horrible_ to implement and, most important, to get right. Yes, you say it's easy. But you implemented it. I also say understanding bcm43xx code is very easy. But I am sure that most people will strongly disagree here. I don't say you misdesigned WE. It was a good solution back when you designed it (1996?). WE is simply showing its age and should be replaced by nl80211. > > I'd much prefer merging nl80211 and putting any really *new* stuff into > > it directly. Of course this fragments the user space API for a while > > since you need to use two APIs then for the time being to configure all > > things, but we can move over all the rest of the configuration gradually > > and before we end up in mainline with the new API we can have that > > finished. > > Good luck with that plan, user-space is notorious to not like > entropy... > 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. It is. Nobody says different. I think with "mainline" Johannes meant the wireless-dev tree. Merging nl80211 with softmac would indeed not make sense to me, too. -- Greetings Michael. - 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
