Re: [KJ][RFC][PATCH] BIT macro cleanup
From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Date: 2007-02-23 14:58:00
Also in:
kernel-janitors, lkml
From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Date: 2007-02-23 14:58:00
Also in:
kernel-janitors, lkml
On 2/23/07, Richard Knutsson [off-list ref] wrote:
Milind Choudhary wrote:quoted
On 2/23/07, Richard Knutsson [off-list ref] wrote:quoted
quoted
+#define BITWRAP(nr) (1UL << ((nr) % BITS_PER_LONG)) & make the whole input subsystem use it The change is huge, more than 125 files using input.h & almost all use the BIT macro.It is as a big of change, but have you dismissed the "BIT(nr % BITS_PER_LONG)" approach?no.. but just looking at the number of places it is being used, it seems that adding a new macro would be good which makes it look short n sweetYou have a point there but I still don't think it should be in bitops.h. Why should we favor long-wrap before byte-wrap, so what do you think about doing: #define BITWRAP(x) BIT((x) % BITS_PER_LONG) in input.h? Otherwise I think it should be call LBITWRAP (or something) to both show what kind it is and enable us to add others later.
Why would you not want to have what you call bitwrap as a standard behavior? Most placed to not use modulus because they know the kind of data they are working with but should still be fine if generic implementation did that. -- Dmitry