From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits() Date: Wed, 13 Dec 2017 17:45:54 +0000 Message-ID: <20171213174554.GE21978@ZenIV.linux.org.uk> References: <20171212120409.64b6362e@cakuba.netronome.com> <20171212234856.GZ21978@ZenIV.linux.org.uk> <20171212155933.03c88eab@cakuba.netronome.com> <20171213003659.GA21978@ZenIV.linux.org.uk> <20171212170437.4b129e50@cakuba.netronome.com> <20171213013056.GB21978@ZenIV.linux.org.uk> <20171212173528.340cd002@cakuba.netronome.com> <20171213015125.GC21978@ZenIV.linux.org.uk> <20171212184400.13b27cf8@cakuba.netronome.com> <20171213142212.GD21978@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: Jakub Kicinski Return-path: Content-Disposition: inline In-Reply-To: <20171213142212.GD21978@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, Dec 13, 2017 at 02:22:12PM +0000, Al Viro wrote: > Next question: where do we put that bunch? I've put it into > linux/byteorder/generic.h, so that anything picking fixed-endian primitives > would pick those as well; I hadn't thought of linux/bitfield.h at the time. > We certainly could put it there instead - it's never pulled by other headers, > so adding #include into linux/bitfield.h is not going to > cause header order problems. Not sure... > > Linus, do you have any preferences in that area? After looking at some of the callers of bitfield.h stuff: it might be useful to add static inline void le64p_replace_bits(__le64 *p, u64 v, u64 mask) { __le64 m = cpu_to_le64(mask); *p = (*p & ~m) | (cpu_to_le64(v * mask_to_multiplier(mask)) & m); } and similar for other types. Not sure what would be a good name for host-endian variants - u64p_replace_bits() sounds a bit clumsy. Suggestions?