Re: [KJ] [RFC][PATCH] BIT macro cleanup

From: Richard Knutsson <ricknu-0@student.ltu.se>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Milind Choudhary <milindchoudhary@gmail.com>,
	kernel-janitors@lists.osdl.org, linux-kernel@vger.kernel.org,
	linux-input@atrey.karlin.mff.cuni.cz,
	linux-joystick@atrey.karlin.mff.cuni.cz
Subject: Re: [KJ] [RFC][PATCH] BIT macro cleanup
Date: Fri, 23 Feb 2007 22:43:44 +0000	[thread overview]
Message-ID: <45DF6E20.9060604@student.ltu.se> (raw)
In-Reply-To: <d120d5000702231358j55cd6665x2add335ceb904c22@mail.gmail.com>

Dmitry Torokhov wrote:
> On 2/23/07, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
>> Dmitry Torokhov wrote:
>> >
>> > Hm, I thought as was clear, but apparently I messed up explaining my
>> > position:
>> >
>> > 1. I don't like BITWRAP name at all and I don't want anything like
>> > that near input code. I think BIT is just fine.
>> Oh, I think I understand now. So the (in input.h):
>> #undef BIT
>> #define BIT(...
>> business is what you want to do? Well, that I will not object to.
>
> No, #undefs may be barely tolerable in .c files but they are not
> acceptable in core subsystem interfaces. If you do that you will never
> know what version of BIT patricular module is using.
Yes, kinda. But wouldn't the compiler complain if you included both 
input.h and bitops.h (multiply definitions of BIT)?
>>  Your
>> patch with:
>> +#define BIT(nr)        (1UL << (nr))
>> +#define LLBIT(nr) (1ULL << (nr))
>> +#define BITWRAP(nr)    (1UL << ((nr) % BITS_PER_LONG))
>> in bitops.h made me believe the #undef in input.h was just a temporarily
>> thing.
>
> No. There is no "my patch". You are confusing me with Milind
> Choudhary. 
Sorry about that. Am surprised I didn't notice it earlier...
> I am saying that IMO input's BIT definition should be
> adequate for 99% of potential users and that I would be OK with moving
> said BIT definition from input.h to bitops.h and maybe supplementing
> it with LLBIT. I am also saying that I do not want BITWRAP, BITSWAP
> (what swap btw?) nor BIT(x % BITS_PER_LONG) in input drivers.
Is the reason for the modulo to put a bitmask larger then the variable 
into an array? I did just a quick 'grep' for "BIT(" in drivers/input/ 
and from what I saw, most (or all?) of the values are defined constants 
and those in input.h were noway near the limits of a 'long'.
The reason I don't like it with modulo is simply because it hides 
potential bugs (when x is to big). And what about the "1%"?
IMHO BIT should be as simple as possible.

Richard Knutsson

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors