> 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 :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
