Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbdLLECe (ORCPT ); Mon, 11 Dec 2017 23:02:34 -0500 Received: from mx3.wp.pl ([212.77.101.9]:38210 "EHLO mx3.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbdLLECc (ORCPT ); Mon, 11 Dec 2017 23:02:32 -0500 Date: Mon, 11 Dec 2017 20:02:24 -0800 From: Jakub Kicinski To: Al Viro Cc: Linus Torvalds , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits() Message-ID: <20171211200224.23bc5df4@cakuba.netronome.com> In-Reply-To: <20171211155422.GA12326@ZenIV.linux.org.uk> References: <20171210045326.GO21978@ZenIV.linux.org.uk> <420a198d-61f8-81cf-646d-10446cb41def@synopsys.com> <20171211050520.GV21978@ZenIV.linux.org.uk> <20171211053803.GW21978@ZenIV.linux.org.uk> <20171211155422.GA12326@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WP-MailID: 5962adec9af5d64f0991b507f3f04678 X-WP-AV: skaner antywirusowy Poczty Wirtualnej Polski X-WP-SPAM: NO 000000A [wdNE] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1291 Lines: 26 On Mon, 11 Dec 2017 15:54:22 +0000, Al Viro wrote: > Essentially, it gives helpers for work with bitfields in fixed-endian. > Suppose we have e.g. a little-endian 32bit value with fixed layout; > expressing that as a bitfield would go like > struct foo { > unsigned foo:4; /* bits 0..3 */ > unsigned :2; > unsigned bar:12; /* bits 6..17 */ > unsigned baz:14; /* bits 18..31 */ > } > Even for host-endian it doesn't work all that well - you end up with > ifdefs in structure definition and generated code stinks. For fixed-endian > it gets really painful, and people tend to use explicit shift-and-mask > kind of macros for accessing the fields (and often enough get the > endianness conversions wrong, at that). With these primitives > > struct foo v <=> __le32 v > v.foo = i ? 1 : 2 <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4) > f(4 + v.baz) <=> f(4 + le32_get_bits(v, 18, 14)) Looks very useful. The [start bit, size] pair may not land itself too nicely to creating defines, though. Which is why in include/linux/bitfield.h we tried to use a shifted mask and work backwards from that single value what the start and size are. commit 3e9b3112ec74 ("add basic register-field manipulation macros") has the description. Could a similar trick perhaps be applicable here?