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

[Richard Knutsson]

Dmitry Torokhov wrote:
> On 2/23/07, Richard Knutsson <ricknu-0@xxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/