On Thursday 31 August 2006 19:12, Jean Tourrilhes wrote:
On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote:
quoted
On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote:
quoted
o modulation
o long/short retry
o relative power saving.
I strongly disagree to these.
And I strongly disagree with your disagrement ;-)
quoted
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.
quoted
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.