[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Ywahn6b92NcrZod0@yury-laptop>
Date: Wed, 24 Aug 2022 15:09:35 -0700
From: Yury Norov <yury.norov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
Dennis Zhou <dennis@...nel.org>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Alexey Klimov <aklimov@...hat.com>,
Kees Cook <keescook@...omium.org>,
Andy Whitcroft <apw@...onical.com>
Subject: Re: [PATCH v2 2/3] lib/find_bit: create find_first_zero_bit_le()
> Just make the macro take that "last word op" as another argument, and
> then you don't need these tricks, and you can do the _le() version in
> lib/find.c file *exactly* like the regular version, using just
>
> #ifdef __BIG_ENDIAN
> unsigned long find_first_zero_bit_le(const unsigned long *addr,
> unsigned long size)
> { return FIND_FIRST_BIT(~addr[idx], swab(val), size); }
> #else
> unsigned long find_first_zero_bit_le(const unsigned long *addr,
> unsigned long size) __alias(find_first_zero_bit);
> #endif
>
> or something like that.
>
> And yes, it means that the "regular" versions need to pass in just
> "val" as a last-word expression, but who cares? It's still cleaner,
> and easier to explain: "The first expression finds the word that
> matches our requirement, the second expression munges the word we
> found into the bit order we use".
OK. I'll do like this:
#define FIND_FIRST_BIT(FETCH, MUNG, size) ...
unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size)
{
return FIND_FIRST_BIT(~addr[idx], /* NOP */, size);
}
unsigned long find_first_zero_bit_le(const unsigned long *addr, unsigned long size)
{
return FIND_FIRST_BIT(~addr[idx], swab, size);
}
It doesn't actually look that worse.
Thanks,
Yury
Powered by blists - more mailing lists