From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935188AbdEVQ7Z (ORCPT ); Mon, 22 May 2017 12:59:25 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53806 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760026AbdEVQ7V (ORCPT ); Mon, 22 May 2017 12:59:21 -0400 Subject: Re: [PATCH] cfg80211: Be able to set bss expire time at config stage. To: Johannes Berg , Dan Williams , "David S . Miller" , linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Dmitry Shmidt , helmut.schaa@googlemail.com References: <20170522160946.2057-1-enric.balletbo@collabora.com> <1495470111.25557.9.camel@redhat.com> <1495470254.26008.3.camel@sipsolutions.net> From: Enric Balletbo i Serra Message-ID: Date: Mon, 22 May 2017 18:59:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1495470254.26008.3.camel@sipsolutions.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 22/05/17 18:24, Johannes Berg wrote: > >> 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. > Ok, guess I understand what you're saying. Thanks for pointing me in the right direction. >> 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 >