Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-13 Thread Jakub Kicinski
On Wed, 13 Dec 2017 14:22:12 +, Al Viro wrote: > IMO it's not worth the trouble; let's go with the check inside of > static inline and accept that on clang builds it'll do nothing. Ack, thanks for investigating!

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-13 Thread Al Viro
On Wed, Dec 13, 2017 at 02:22:12PM +, 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 p

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-13 Thread Al Viro
On Tue, Dec 12, 2017 at 06:44:00PM -0800, Jakub Kicinski wrote: > On Wed, 13 Dec 2017 01:51:25 +, Al Viro wrote: > > On Tue, Dec 12, 2017 at 05:35:28PM -0800, Jakub Kicinski wrote: > > > > > It used to be __always_inline, but apparently LLVM/clang doesn't > > > propagate constants :( > > >

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Jakub Kicinski
On Wed, 13 Dec 2017 01:51:25 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 05:35:28PM -0800, Jakub Kicinski wrote: > > > It used to be __always_inline, but apparently LLVM/clang doesn't > > propagate constants :( > > > > 4e59532541c8 ("nfp: don't depend on compiler constant propagation") >

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Al Viro
On Tue, Dec 12, 2017 at 05:35:28PM -0800, Jakub Kicinski wrote: > It used to be __always_inline, but apparently LLVM/clang doesn't > propagate constants :( > > 4e59532541c8 ("nfp: don't depend on compiler constant propagation") Doesn't propagate constants or doesn't have exact same set of rule

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Jakub Kicinski
On Wed, 13 Dec 2017 01:30:56 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 05:04:37PM -0800, Jakub Kicinski wrote: > > On Wed, 13 Dec 2017 00:36:59 +, Al Viro wrote: > > > On Tue, Dec 12, 2017 at 03:59:33PM -0800, Jakub Kicinski wrote: > > > > > +static __always_inline __##type type##_rep

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Al Viro
On Tue, Dec 12, 2017 at 05:04:37PM -0800, Jakub Kicinski wrote: > On Wed, 13 Dec 2017 00:36:59 +, Al Viro wrote: > > On Tue, Dec 12, 2017 at 03:59:33PM -0800, Jakub Kicinski wrote: > > > > +static __always_inline __##type type##_replace_bits(__##type old, > > > > \ > > > > +

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Jakub Kicinski
On Wed, 13 Dec 2017 00:36:59 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 03:59:33PM -0800, Jakub Kicinski wrote: > > > +static __always_inline __##type type##_replace_bits(__##type old, > > > \ > > > + base val, base mask)\ > > > +{

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Al Viro
On Tue, Dec 12, 2017 at 03:59:33PM -0800, Jakub Kicinski wrote: > > +static __always_inline __##type type##_replace_bits(__##type old, \ > > + base val, base mask)\ > > +{ \ > > + __##t

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Jakub Kicinski
On Tue, 12 Dec 2017 23:48:56 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 12:04:09PM -0800, Jakub Kicinski wrote: > > > > static __always_inline u64 mask_to_multiplier(u64 mask) > > > { > > > return mask & (mask ^ (mask - 1)); > > > } > > D'oh. Even simpler than that, of course - > > sta

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Al Viro
On Tue, Dec 12, 2017 at 12:04:09PM -0800, Jakub Kicinski wrote: > > static __always_inline u64 mask_to_multiplier(u64 mask) > > { > > return mask & (mask ^ (mask - 1)); > > } D'oh. Even simpler than that, of course - static __always_inline u64 mask_to_multiplier(u64 mask) { return m

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Jakub Kicinski
On Tue, 12 Dec 2017 19:45:32 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > > > Umm... What's wrong with > > > > #define FIELD_FOO 0,4 > > #define FIELD_BAR 6,12 > > #define FIELD_BAZ 18,14 > > > > A macro can bloody well expand to any sequence of tokens - le

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-12 Thread Al Viro
On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > Umm... What's wrong with > > #define FIELD_FOO 0,4 > #define FIELD_BAR 6,12 > #define FIELD_BAZ 18,14 > > A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, > FIELD_BAZ) > will become le32_get_bits(v, 18, 14) j

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-11 Thread Al Viro
On Mon, Dec 11, 2017 at 08:02:24PM -0800, Jakub Kicinski wrote: > On Mon, 11 Dec 2017 15:54:22 +, 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 w

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-11 Thread Jakub Kicinski
On Mon, 11 Dec 2017 15:54:22 +, 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;

[RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

2017-12-11 Thread Al Viro
A lot of drivers are open-coding the "replace these bits in __be32 with the following value" kind of primitives. Let's add them to byteorder.h. Primitives: {be,le}{16,32,64}_replace_bits(old, v, bit, nbits) {be,le}{16,32,64}_get_bits(val, bit, nbits) Essentially, it gives helpers