Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp927987ybi; Wed, 3 Jul 2019 06:47:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdOY4VzxsRf+qObGU2v3mHgx3xsBFYL3H+fsoTbS5JMPYjrY6qbA7qv8O0n3g3+Jj11+qi X-Received: by 2002:a17:902:2e81:: with SMTP id r1mr42985195plb.0.1562161652002; Wed, 03 Jul 2019 06:47:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562161651; cv=none; d=google.com; s=arc-20160816; b=CHLCaCyx1pVLh8+GChUtwuE2gygbQHeDAx97uH41SOTAmoPBGK4YV4y7zptKElQNqw 6Q7kEsnGVn3/W3OTE+avbchaArDp/gKhIwg9jLgoF1bTC3saRLQ2CKOIGgcBAk3Rcglo 1gjmIFku202gvNCjQ+pWzjXyqkksgKQO+EByRgKNBajwj8Hd0n75HMU3AD1R+z8cIdTU vGR2j+sg1MSZmzc73inJVTs8vLNM+WnCMQUcVAWz072F/zD8wgvxpckALB42cwf6P8wV CbrxpgkkpBTY4D3mE8dFXqIwhwzm49Yp6h/EyjgM4BRDTnhbJ3ZAWS9lSqIC15VanU6a EQWA== 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=5M7V3WKdCO2x7rPXbtCpLilGZo3GaCh2wU8CxF73Vzw=; b=M6zCXxLHgO8S9Q35eT2TJTkwfle+xys3OZn21bLiIv2nkzieVIrGpwGOvuQWuymg0J gTkUV9J/0UKCpOpwHmyfDOJsIC3IbvwYY1GKczvM01A48CDsM8Fb8ZJCi6VDF9QYatLz RITVoLVVte482zDyN8YrdcpU2I8kIWHGR78kyJh5pTns+2gNJPXldb9iPQBdv7JPNlxr M6a5Ls15MR4e1XPW6Y+YiD1DUtQR98cLIkLCogMRG69TRwN/uJWy1GX4rj9MJrTx/vC/ L3+t5YntM0Ylp3QdVvprBBh7EzGTuKLy7V8TQExG/D1okEckXtKK1jXVS4m5c382kvaW AJyA== 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 u6si2330728pga.360.2019.07.03.06.47.16; Wed, 03 Jul 2019 06:47:31 -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 S1726871AbfGCNpJ (ORCPT + 99 others); Wed, 3 Jul 2019 09:45:09 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:38540 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfGCNpI (ORCPT ); Wed, 3 Jul 2019 09:45:08 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hifZC-0000hr-Hn; Wed, 03 Jul 2019 15:44:58 +0200 Message-ID: Subject: Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling From: Johannes Berg To: Jiri Pirko , Michal Kubecek Cc: David Miller , netdev@vger.kernel.org, Jakub Kicinski , Andrew Lunn , Florian Fainelli , John Linville , Stephen Hemminger , linux-kernel@vger.kernel.org Date: Wed, 03 Jul 2019 15:44:57 +0200 In-Reply-To: <20190703114933.GW2250@nanopsycho> (sfid-20190703_134935_025840_EF167268) References: <20190703114933.GW2250@nanopsycho> (sfid-20190703_134935_025840_EF167268) 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 Wed, 2019-07-03 at 13:49 +0200, Jiri Pirko wrote: > > > +Value and mask must have length at least ETHTOOL_A_BITSET_SIZE bits rounded up > > +to a multiple of 32 bits. They consist of 32-bit words in host byte order, > > Looks like the blocks are similar to NLA_BITFIELD32. Why don't you user > nested array of NLA_BITFIELD32 instead? That would seem kind of awkward to use, IMHO. Perhaps better to make some kind of generic "arbitrary size bitfield" attribute type? Not really sure we want the complexity with _LIST and _SIZE, since you should always be able to express it as _VALUE and _MASK, right? Trying to think how we should express this best - bitfield32 is just a mask/value struct, for arbitrary size I guess we *could* just make it kind of a binary with arbitrary length that must be a multiple of 2 bytes (or 2 u32-bit-words?) and then the first half is the value and the second half is the mask? Some more validation would be nicer, but having a generic attribute that actually is nested is awkward too. johannes