From: Johannes Berg <johannes@sipsolutions.net>
To: Dan Williams <dcbw@redhat.com>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
"David S . Miller" <davem@davemloft.net>,
linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Dmitry Shmidt <dimitrysh@google.com>,
helmut.schaa@googlemail.com
Subject: Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.
Date: Mon, 22 May 2017 18:24:14 +0200 [thread overview]
Message-ID: <1495470254.26008.3.camel@sipsolutions.net> (raw)
In-Reply-To: <1495470111.25557.9.camel@redhat.com>
> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
> create its own list? Given that the kernel provides the information
> userspace needs to figure out the age of a particular BSS, it doesn't
> seem like there needs to be a kernel tunable for this. Userspace can
> already avoid stale results.
Yeah, I agree. It can also ask for a flush, so that old results are
gone by the time the next scan returns. We don't have a flush operation
without requesting a new scan, but I guess that could be added.
> Also, different runtime situations might want different result ages,
> which wouldn't be possible if the kernel had a hardcoded maximum.
> Furthermore, different userspace apps might be reading the same scan
> list, and they might have different ideas about staleness.
>
> Or perhaps I misunderstand the problem, which could well be the case.
No, I think this is perfectly right - userspace should be able to deal
with this given the tools we gave it, or if not, we should probably
just give it more tools instead of hardcoding the kernel configuration.
This value really just kinda needed to be an upper bound so that we
don't start expiring entries while we're still scanning.
johannes
next prev parent reply other threads:[~2017-05-22 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 16:09 [PATCH] cfg80211: Be able to set bss expire time at config stage Enric Balletbo i Serra
2017-05-22 16:19 ` Johannes Berg
2017-05-22 16:34 ` Johannes Berg
2017-05-22 16:21 ` Dan Williams
2017-05-22 16:24 ` Johannes Berg [this message]
2017-05-22 16:59 ` Enric Balletbo i Serra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1495470254.26008.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=dimitrysh@google.com \
--cc=enric.balletbo@collabora.com \
--cc=helmut.schaa@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).