Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2104656ybi; Thu, 4 Jul 2019 05:18:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqy4EYl+vctw6KFwcrYsJe+CxwpebmDDulmMn1EfMzQ3Z2wKysButb039eYkiK8z/OHXoIPS X-Received: by 2002:a65:4b8b:: with SMTP id t11mr34725200pgq.130.1562242695395; Thu, 04 Jul 2019 05:18:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562242695; cv=none; d=google.com; s=arc-20160816; b=rLlk2RTpmBq0Xg/Sco3PkuubF2b5FrmKgUg5dzPJO1/7RLR94uzkOFsLO2+j/cpEgZ lKESLdoiz75HtRxXeMYJ4z423SulztaioN+2S1izz+AZ55kD41jcfJNKZJc9Nri4epMx XW2bKqyY7cdz37lGuC6dTLRTyYTQgUiZjVkPIRqS1cyoNhRIpIO290Yg9WJnNXEEISAW J5bZJ7VuZLdVVkN4FjH/q20DpxrCfDZSW68+Lo4KN9562IgN0pxw/qVeXE8WBcp4xO6v h5Dnw9nlSAbJBpYQW0iGK1u/Lr5eDNx2y/O2EX8MFJW4wCNrS47bBe9Hi8Ezw14rXD7z bUig== 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; bh=3RlBCdoSMcSM3QO6pwDv3EcEfsHP0cJ1cRp6PTbLiGw=; b=UGveanrZlpJdxzF8BXL37003d7lpsCjGxt/YAAe5bx7nFxNyUCUTT6+Aam9y4G8c8t Dw7iIGRG7Ye9ASHzIOuHrUdh6LfpG/oO+rxGJPbJvGOTVe950HTnGQpNenpMImWvjhFC HQ8Tf824lFgX8qYQj7q1r1AMaJVQ/uwMfXlDSgA7vbsFXE0TN5vwj6lz0ZFMezzXof51 XL5IlGT1PH+bR0ywgNViorDXOXgCWMY2Qt+t765aFafapMX2gTf/FPQMDzuAXe9qvXW8 AtRfmzrpbdDRNEvV64i69K1mOFA9K30nMEiV4IPkPYXVDTHlwJS8gv1CA7SRmUP/Gsu7 eU7g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c5si5417785pgd.182.2019.07.04.05.18.00; Thu, 04 Jul 2019 05:18:15 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727727AbfGDMRV (ORCPT + 99 others); Thu, 4 Jul 2019 08:17:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:57002 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727675AbfGDMRU (ORCPT ); Thu, 4 Jul 2019 08:17:20 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 94B2AAC98; Thu, 4 Jul 2019 12:17:19 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id DB3D2E0159; Thu, 4 Jul 2019 14:17:18 +0200 (CEST) Date: Thu, 4 Jul 2019 14:17:18 +0200 From: Michal Kubecek To: netdev@vger.kernel.org Cc: Johannes Berg , Jiri Pirko , David Miller , Jakub Kicinski , Andrew Lunn , Florian Fainelli , John Linville , Stephen Hemminger , linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling Message-ID: <20190704121718.GS20101@unicorn.suse.cz> References: <20190703114933.GW2250@nanopsycho> <20190703181851.GP20101@unicorn.suse.cz> <20190704080435.GF2250@nanopsycho> <20190704115236.GR20101@unicorn.suse.cz> <6c070d62ffe342f5bc70556ef0f85740d04ae4a3.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c070d62ffe342f5bc70556ef0f85740d04ae4a3.camel@sipsolutions.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 04, 2019 at 02:03:02PM +0200, Johannes Berg wrote: > On Thu, 2019-07-04 at 13:52 +0200, Michal Kubecek wrote: > > > > There is still the question if it it should be implemented as a nested > > attribute which could look like the current compact form without the > > "list" flag (if there is no mask, it's a list). Or an unstructured data > > block consisting of u32 bit length > > You wouldn't really need the length, since the attribute has a length > already :-) It has byte length, not bit length. The bitmaps we are dealing with can have any bit length, not necessarily multiples of 8 (or even 32). Michal