[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyyiRjAhGGK_6Ap21zY+NRttQZGjdxpR9_DzA5X7cGobw@mail.gmail.com>
Date: Mon, 5 Dec 2016 09:13:26 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sebastian Frias <sf84@...oste.net>
Cc: zijun_hu <zijun_hu@....com>, Sasha Levin <sasha.levin@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mason <slash.tmp@...e.fr>,
Maxime Coquelin <maxime.coquelin@...com>,
Harvey Harrison <harvey.harrison@...il.com>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields
On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias <sf84@...oste.net> wrote:
> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with
> continuous bitfields, just as BIT(x) does for single bits.
>
> SETBITFIELD_ULL(msb, lsb, value) macro is also added.
No. No, no, no.
Didn't we have this discussion already? Or was that for one of the
other silly naming things?
That thing doesn't "SET" anything at all. It generates a value, nothing more.
So the name is completely unacceptable. It follows the convention of
GENMASK, so maybe GENVALUE?
I also absolutely hate the stupid "big bit first" idiocy, but we did
that for GENMASK too, so I guess we're stuck with that retarded model.
Yes, I understand why it happened - people look at register definition
graphics, and the high bits are to the left.
But when you then read the documentation, it will still say things
like "bits 9 through 12 contain the value XYZ", because while
individual numbers are written MSB first, we actuall _read_ left to
right. You'd never give a range as "12 to 5", you'd say "5 to 12".
Linus
Powered by blists - more mailing lists