Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1354920ybl; Fri, 16 Aug 2019 13:30:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqyW5BVXiL4D1wkPqA3m0d3rnmvTwt349u2gUETln0EN5RHsQrShjNVLcaPgmrHMvdqU7yF3 X-Received: by 2002:aa7:818b:: with SMTP id g11mr12710615pfi.122.1565987429513; Fri, 16 Aug 2019 13:30:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565987429; cv=none; d=google.com; s=arc-20160816; b=kvpwX2EoHy1kmcXIaTObptJXxnJyEzC+yWglQoT6dcWO+4HVNmJMsuQiGQa2SdeiPO x1t+dIa5MTiyzp8jJs5K5r93F3GqxoAazyOT0Obg0XAXSywiJiIOWoKzas+BereD7NV/ 76bzv/fvuCcYBbP68gekwzFqKElcgoMkgvOGh8RVsZGKtqtd5ZvZR9YkYVmpJUj+GqNw JCG4zlbdERJyITA766SnKmooFxDZL90Vn/Bu9u99Wzkx+ckrYKQPPX+hw64BDM3PDDFd 9oiD2N5u1+pbrTsv93ZxtV6TIJAIrCzc2tvhkMlLyd5kkFkEv8R+6hf9rcCdo2Diw8KK fsYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=4Z4kcycmk7cP+X6ruCeRZgpDdYRmawH/3B5+atDz6nM=; b=IBuVNJMuuWk4LDxfAEo7urDA/hEdpafOw2NFUCHPJBPHn2/5I1pLKech5NNZGXrHgc c3eQ5QDmgL/qCYZ7eW7L0ELarfSGtci2XCpxrvTPQFvzEqRsnrzlx3zCZzjSzX1N/ZLX zmUyEe3Rhd1cixRiMjTQi8MtXzhBiX91Mm07o7CHmY/Ce22QGvxhi0+JvcCA1bqMqF9h ejsukIbIQfWPQ5pKN5QKLCbhh39bsNtf7IihgAoA81FyxedbtUxYMBRKmGZv+hqvKSaO uiWEgZzAD7jaoUvEBnkUfu/ojQtc0G0kNTKXZWbKM3E2FUMllGYbExAH+Fp3tPeT7wrl N+9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=kdMfWNYx; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 6si4625696pla.88.2019.08.16.13.30.08; Fri, 16 Aug 2019 13:30:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=kdMfWNYx; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727646AbfHPU37 (ORCPT + 99 others); Fri, 16 Aug 2019 16:29:59 -0400 Received: from mail-lj1-f179.google.com ([209.85.208.179]:34493 "EHLO mail-lj1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727620AbfHPU37 (ORCPT ); Fri, 16 Aug 2019 16:29:59 -0400 Received: by mail-lj1-f179.google.com with SMTP id x18so6417169ljh.1 for ; Fri, 16 Aug 2019 13:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Z4kcycmk7cP+X6ruCeRZgpDdYRmawH/3B5+atDz6nM=; b=kdMfWNYxRBQt7UqSOZP8fc4rSV24B34+D4K+MTmLYp/5pNhZ3FjFSfJEluohR8ERfc fdvmWrJ3c8GBAEUPzosu3IRGmB1JR0dW5wlm2O9N0wqL49F9YKQHwyLsL815FLJ3aIo9 RJoOVkaTschZpJNaIJMVQQd1uYjg20OBbuyOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Z4kcycmk7cP+X6ruCeRZgpDdYRmawH/3B5+atDz6nM=; b=Lg5WDphGbleIkvVnJ4EsifJEMyFTPE6hbTMats/aSreg9ILhz30CxAjQ9S9W3M+i/z gzSuP+RLoydUZF1mVa1uYWHt5KZaJaPIZSEpG8Z78eeAWn17e+om7VBg/j33c+DPWy+T AT5CiBBQ2Tkkej+COna4jGo0/1JRxTCwY0zX2vVWsWnw8d5j7nkTfesknRa/6tdsMbX3 c7KhYrpeyrws9DfHEXaNH0Yf9iTTLUACwjdio95p6nmbjgfFp6Amx5LUQfcTeoDw3N8a 1+gbECFxDqLlkhEQ2ZOVNdsZCsTgHNQ4IOml9p5AVO+SuBXMbCi21Qg1CtN3iv4ztJj7 zrRg== X-Gm-Message-State: APjAAAUcUTG+0Xy/f8/COx/iAxJwOLmd9BJnOtSFl3OPZRI8pmuStIYj 4d2ELmkd9wBInke7M0JOM43OxgNs984= X-Received: by 2002:a2e:7a07:: with SMTP id v7mr6604675ljc.105.1565987396528; Fri, 16 Aug 2019 13:29:56 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id h15sm1111714ljl.64.2019.08.16.13.29.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2019 13:29:55 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id j17so4917964lfp.3 for ; Fri, 16 Aug 2019 13:29:54 -0700 (PDT) X-Received: by 2002:ac2:5ec3:: with SMTP id d3mr5998456lfq.44.1565987394528; Fri, 16 Aug 2019 13:29:54 -0700 (PDT) MIME-Version: 1.0 References: <20190403210200.GA93453@google.com> <211816ff03cf188d834a21b1fbc98b4f8c5b81f4.camel@sipsolutions.net> <7687225C-D965-479E-BAE8-769B0AEADD76@holtmann.org> In-Reply-To: <7687225C-D965-479E-BAE8-769B0AEADD76@holtmann.org> From: Brian Norris Date: Fri, 16 Aug 2019 13:29:43 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Flag for detecting 802.11r Fast BSS Transition support To: Marcel Holtmann Cc: Johannes Berg , Matthew Wang , linux-wireless , Kirtika Ruchandani , Jouni Malinen Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi Marcel, On Fri, Aug 16, 2019 at 11:54 AM Marcel Holtmann wrote: > > Well, I guess we could just run the command and look for EOPNOTSUPP... > > this kind of API design and usage is bad. Try-and-error approach is just not sustainable. Sure. That "suggestion" was quite literally an afterthought. Not really a proper suggestion. > Even while it is late to add a proper flag that indicates support, we need to do this to make nl80211 better for the future. I suppose. I'm not quite sure how I would make use of that properly though, given the corpus of kernels out there where the flag doesn't exist (but the feature does). Some other heurestic for determining kernel recency? Compile-time flags for the relevant user space, such that one builds it for "new kernel API (w/ flag)" vs. "old kernel API" (with the latter not even trying to look for the flag)? Or I guess a more proactive approach: implement both a "supported" and an "unsupported" flag, so user space can figure out a tristate: flag not available (old kernel -- user space is left to guess) vs. command supported flag vs. command not supported flag. That seems a bit awkward though. Brian