Return-path: Received: from mail-fx0-f221.google.com ([209.85.220.221]:60388 "EHLO mail-fx0-f221.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753249AbZKJLTj (ORCPT ); Tue, 10 Nov 2009 06:19:39 -0500 Received: by fxm21 with SMTP id 21so837863fxm.21 for ; Tue, 10 Nov 2009 03:19:44 -0800 (PST) Date: Tue, 10 Nov 2009 12:19:11 +0100 Message-ID: From: Holger Schurig To: Johannes Berg Cc: Holger Schurig , linux-wireless Subject: Re: [RFC] cfg80211: survey report capability In-Reply-To: <1257848249.7037.30.camel@johannes.local> References: <1257848249.7037.30.camel@johannes.local> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-wireless-owner@vger.kernel.org List-ID: > Nit: missing newline Done > > +enum survey_info_flags { > > + SURVEY_INFO_CHANNEL = 1<<0, > > + SURVEY_INFO_NOISE = 1<<1, > > A response w/o a channel seems entirely useless, shouldn't we just > require a channel? Hey, libertas could respond just the noise and no channel. But it could then also respond with the channel, it's there anyway. > For mBm, an s8 won't be enough I think? -90 dBm == -9000 mBm? Oh, sure. > You need to construct a nested attribute here and put the values into it > so that the callback can be invoked multiple times, once for each > channel. OTOH, when there are many many channels that will overrun the > message size at some point and we'll pull our hair (like we're doing now > with the channel list in phy info) ... so I'd prefer you move this to a > dump-style model like dump_stations has. Okay. Or maybe a little bit more nl80211_dump_scan. > Right now you're retrieving a single channel but can't even control > which one. Idea was to retrieve as many channels as the drivers sends using the callback. Controlling what should be returned should be done after either enhancing scan-trigger or writing a new survey-trigger command. So survey-dump would be very similar to scan-dump: return as much data as is available (and not stale). And this could very well be only one channel. And in absence of survey-trigger or an enhanced-scan trigger it will certainly only report info about the current channel. > Maybe that's useful functionality in addition to dump when you _can_ > ask for information on a specific channel, but that'd have to pass > in the frequency from userspace. Would this then be useful for the scan-dump command as well? > Retrieving all data like you've implemented (though I guess you forgot > the multiple channels case) should be a dump. I did not forgot about the multi-channel case, I forgot about the nesting. /me's still learning nl80211 :-)