On Tue, 2009-02-17 at 21:24 +0100, Marcel Holtmann wrote: > > 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
