Re: Missing link quality with wireless-testing

[Marcel Holtmann <marcel@holtmann.org>]

Hi Johannes,

> > > What exactly is broken by this? Wext never guaranteed that 'qual' values
> > > be present, and thus any application that breaks from not having 'qual'
> > > is broken anyway.
> > 
> > that be it, but I would still consider this a regression. Since when do
> > we just start removing API details without any proper warning or grace
> > period?
> 
> Why not? The API even contains whether or not the values are valid, and
> after discussing with many of the stakeholders (network manager,
> wpa_supplicant) we've decided that there's little use in the qual.qual
> value. Especially since you want to compare the 'quality' of the AP
> against the one you're associated to, so qual isn't really useful at all
> due to the various factors it can contain.
> 
> So hey, if you want to scream "regression" then we can add a 'qual.qual'
> value back. It'll still be entirely pointless, and I'll still be against
> it, but I'm not going to risk anyone reverting this patch, it's way too
> useful. And if you're going to scream regression then please keep in
> mind that then you're going to scream about the wext limit again... I
> can't fix it up in the next couple of weeks anyway.

remember that I am all for replacing WEXT and getting rid of it, but we
need to be careful with just removing parts of the API in the middle
without people noticing. At least I missed it. So you can argue that it
is my fault, but I think it is not really clear to everybody that this
value is missing now with future kernel versions.

And that WEXT doesn't guarantee that qual.qual is present is not a
really good point since cfg80211 in the past did fill in this value.

So if you really wanna remove this value (and I agree with the argument
that it is not useful), then we should do this gracefully. Using the
feature-removal-schedule.txt document comes to my mind.

Regards

Marcel