On Tue, 2009-11-10 at 12:19 +0100, Holger Schurig wrote:
> > > +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.
But for the multi-channel use case, not having a channel will mean
userspace has no idea what the value means ... it's useless without a
channel I think.
> 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).
Right.
> > 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?
Not sure .. would you want to get scan results for just a single
channel? But we can always add that later if we wanted to, I don't think
it makes a whole lot of sense for either of them.
> > 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 :-)
:)
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
