Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1234320imm; Fri, 29 Jun 2018 14:02:13 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLpjcYOjWvEC6GeTvUZWpXrvt74a1/NhqdOA5en8cWJZHWBGwdYxLXATlQZvxLwtRU85Un8 X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr16216653pls.237.1530306133001; Fri, 29 Jun 2018 14:02:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530306132; cv=none; d=google.com; s=arc-20160816; b=ho3Ytq/kpEvaRwpHVMKV8UeSml/YCOUkN7UYKCK8sI7DIb207tzqpKqwLePDY12J8P moHg7mzpCUBmyAAW9cYUld40IPaTPBNgrebaZhJ3ybfZbtCnalT1mVS7n41YuLsAdbEF B8DmNxGE6ZMDPra1Dkb6t9DMA5YUTfb67H9Zun54s5Lx8/KqK+Ko3yFRzLnqoWx2R5Wy 5MYfeZ/o1aggir/jjMKSIXVikdnOczgeg6afZq30WU2EmCdEUpoerBwWZD4oP9Wwa6VB lHaYOEYRxqUpf++PHieZx5BO7Yge2Z8YkGtlS+gz/TwrPgEK8HLFQtif5jlLGQVCqpSx B71g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=B2Bi6Kc1QYq40IqUU3e8QlrpOWsIuoa8e/TYwjoVXlQ=; b=o3Leat6baojKOR0tRMTVqouiM0/oGBPLprzzqLZxblJbQ340qxNYhc7nsktW3QAscJ lVBsQeVA64JfbLMl8Jdc6Z66CMwPsiw/02cSCWw+TbgCnzzgUl19b7ygV5DwU5saYzMR lnI4C/eE914CkbqPYZXZyysoGaNxWdQttVG9CGO9Mb6ltSKoVif+ua8skYQuCOpGD6jM AQqJpuyqI56x+5HG4CZwbiKP5SYW6y23bCdb5SJ587VQH6tQZnc3jC0k4UTv2N7FWb1T TkhAqN9TFY2Ul+i398xJSvSp1QyYyUizavm818TotVH3rM+TD36NKxzpAnfqb/Xt3g// qs7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=fG5Z7+4F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 a19-v6si9677910pfo.10.2018.06.29.14.01.58; Fri, 29 Jun 2018 14:02:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=fG5Z7+4F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S936600AbeF2Ss4 (ORCPT + 99 others); Fri, 29 Jun 2018 14:48:56 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:35619 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934305AbeF2Ssx (ORCPT ); Fri, 29 Jun 2018 14:48:53 -0400 Received: by mail-pg0-f67.google.com with SMTP id i7-v6so4361747pgp.2 for ; Fri, 29 Jun 2018 11:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=B2Bi6Kc1QYq40IqUU3e8QlrpOWsIuoa8e/TYwjoVXlQ=; b=fG5Z7+4F27+Sa0/SlfXLz++8lycxG0MK0NojgXb5njPeNJ9gx2RClygR13EA7GahAg Bl5QBPsOgfjRuBHxSNJx4FSW13RCN+MUJ1KLvJcQb0GPZDPz1gmYMjCs+q9udml+K0K7 VmzO6YJTlSXekaURZlJdBB7PFejHAeu76vOKY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=B2Bi6Kc1QYq40IqUU3e8QlrpOWsIuoa8e/TYwjoVXlQ=; b=mmL4HnJwKGlTMEa+72sBJN3zAlVbP9XkoIEF5YmxROmxo2KvLZlbmmneDn3Nrk6adn aHNWvfx6eAIWr8ur9UueT5hQOflhKxdv2S6R5DKB9dHTL9i4XqgPq5oUP1cjNlzwqtlr N3w1yfikBfrqnbLaTIyKh0EeMF2uzA1a3WhfLNwtaha5NF2HZV6J1TOQniVB2E2fWJCH td/hGen70CoLZUoGruPN5lQYKOvQx9dJKtMlB70qX3/9fJ5B2iTf54nIENSkfEIC4CIl ko5ekxPRdR30KRm7M+T7pX6RqJDsFV8IJf64WD91BjxanG4OeUXtL6r5pFPcXVVDMRGe Bu4Q== X-Gm-Message-State: APt69E3QBK7/BMr7L30x2xEpQ3gJE+BOIzD40jPXyVE6NHTT0bTpP6bF DUCL7xhSOxAUBPNoZn3fAX2Afg== X-Received: by 2002:a62:5247:: with SMTP id g68-v6mr15700994pfb.149.1530298133184; Fri, 29 Jun 2018 11:48:53 -0700 (PDT) Received: from ban.mtv.corp.google.com ([2620:0:1000:1501:bc2f:3082:9938:5d41]) by smtp.gmail.com with ESMTPSA id f12-v6sm2799581pgt.57.2018.06.29.11.48.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Jun 2018 11:48:51 -0700 (PDT) Date: Fri, 29 Jun 2018 11:48:48 -0700 From: Brian Norris To: Johannes Berg Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] cfg80211: use IDA to allocate wiphy indeces Message-ID: <20180629184847.GA251207@ban.mtv.corp.google.com> References: <20180621012945.185705-1-briannorris@chromium.org> <1530258140.3481.4.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1530258140.3481.4.camel@sipsolutions.net> User-Agent: Mutt/1.10+33 (2f90ec28cf74) (2018-06-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johannes, On Fri, Jun 29, 2018 at 09:42:20AM +0200, Johannes Berg wrote: > On Wed, 2018-06-20 at 18:29 -0700, Brian Norris wrote: > > It's annoying to see the phy index increase arbitrarily, just because a > > device got removed and re-probed (e.g., during a device reset, or due to > > probe testing). We can use the in-kernel index allocator for this, > > instead of just an increasing counter. > > I can understand that it's somewhat annoying to people, but it was > actually done on purpose to avoid userspace talking to the wrong device. Hmm, interesting. I'm not dead-set on this patch, so if there are good reasons to reject it, I won't fret. > Imagine you have some userspace process running that has remembered the > wiphy index to use it to talk to nl80211, and now underneath the device > goes away and reappears. This process should understand that situation, > and handle it accordingly, rather than being blind to the reset. How is this different from the wlan (netdev) device naming? We allow 'wlan0' to leave and return under the same name. Isn't the right answer that user space should be listening for udev and/or netlink events? Brian