Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2111166ybi; Thu, 4 Jul 2019 05:23:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyfVHiSTmNc+GJT8bCgCiEJ+rhsxVKQsCfwpgtFjX9NZmGaCAmi1mYufpsmp8gyLFtjFX// X-Received: by 2002:a17:90a:ab0b:: with SMTP id m11mr20052007pjq.73.1562243036174; Thu, 04 Jul 2019 05:23:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562243036; cv=none; d=google.com; s=arc-20160816; b=a6674bFoyATLsCdFdImrf8vmaEeaH6aOS8dbQQ500h3qY196dhyCdFtHlDBMriwUAb b5AkNE/624foyzumK6WEHEi9uvYqFvUqjzr9quMquFmsSX7EehcTg/mixv2yE1Wb81SR 7vECYFT+G62QeYTtVxZpVRUMALKai8QrtDwEK8QZdJfNIMA1ENPbL8hlW+AqSzsmJaDe TeJrJ8h9deT6l9WytvT3i8wd52yMuCyFY4vN3/DON0j63gvZIIuLYQlKyQSo7yoX9r5V +ZveOltrIizqLdaNrpY2JSHmVjztyb0BtNhztWjY1VmbcefjpidSvowW4CQyj/dsCKbo 3P3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=I0doGR+okwjGYpT44naAKV/Q3m3zAmbA5YjlVK7QT6I=; b=pIzgfYBke96Wc9GACP9cCcOG1qc8LULjXpIqW2UA1+t11pIH0e06qZ3OxQKJWrMoo7 VOykBMuTxLnJVoKd2lQkH/Lpa4TJZXWQLRTEqwf51NHQ0Jz26IRUsoUcCYmOI4UJMcAQ 3po5a5Kx+0v2RMqgEg1L9iltltyZ7v1DU/DC+8kwkN5z+qmZJci1Az4J/EFN5yC/rmj1 nIKxb8dD2625FBCJYp+Y61Mhai9MKKsXeZkvSdTrXrlkLpv2xwGxQExAsUxn5GX+48Sm FJirZwID6k69WEQ157M4sVqh5zZMnfri6XGCIQ1u/2Ry6/RAQTKwKLyRrXM3oxZR1JUk rb/g== 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 y65si5072018pgd.487.2019.07.04.05.23.40; Thu, 04 Jul 2019 05:23:56 -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 S1727760AbfGDMWA (ORCPT + 99 others); Thu, 4 Jul 2019 08:22:00 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:33462 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727614AbfGDMV7 (ORCPT ); Thu, 4 Jul 2019 08:21:59 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hj0kL-0005pG-4r; Thu, 04 Jul 2019 14:21:53 +0200 Message-ID: <2f1a8edb0b000b4eb7adcaca0d1fb05fdd73a587.camel@sipsolutions.net> Subject: Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling From: Johannes Berg To: Michal Kubecek , netdev@vger.kernel.org Cc: Jiri Pirko , David Miller , Jakub Kicinski , Andrew Lunn , Florian Fainelli , John Linville , Stephen Hemminger , linux-kernel@vger.kernel.org Date: Thu, 04 Jul 2019 14:21:52 +0200 In-Reply-To: <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> <20190704121718.GS20101@unicorn.suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-3.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-07-04 at 14:17 +0200, Michal Kubecek wrote: > 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). Not sure why that matters? You have the mask, so you don't really need to additionally say that you're only going up to a certain bit? I mean, say you want to set some bits <=17, why would you need to say that they're <=17 if you have a value: 0b00000000'000000xx'xxxxxxxx'xxxxxxxx mask: 0b00000000'00000011'11111111'11111111 johannes