linux-kernel - Re: [KJ][RFC][PATCH] BIT macro cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b44d3fb0702230215o2fbd5a3y25729e481a447149@mail.gmail.com>
Date:	Fri, 23 Feb 2007 15:45:21 +0530
From:	"Milind Choudhary" <milindchoudhary@...il.com>
To:	"Richard Knutsson" <ricknu-0@...dent.ltu.se>
Cc:	kernel-janitors@...ts.osdl.org, linux-kernel@...r.kernel.org,
	dmitry.torokhov@...il.com, linux-input@...ey.karlin.mff.cuni.cz,
	linux-joystick@...ey.karlin.mff.cuni.cz
Subject: Re: [KJ][RFC][PATCH] BIT macro cleanup

On 2/23/07, Richard Knutsson <ricknu-0@...dent.ltu.se> wrote:
> > +#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 sweet


> I really think this has to be broken down into a patch-set.
yes

> > -#define BIT(i)         (1UL << ((i)&(__NFDBITS-1)))
> Are you sure you can just delete this one?
yes...no users in this file

> <snip>
> > diff --git a/include/linux/input.h b/include/linux/input.h
> > index bde65c8..e4203d1 100644
> > --- a/include/linux/input.h
> > +++ b/include/linux/input.h
> > @@ -908,9 +908,11 @@ struct ff_effect {
> > #include <linux/fs.h>
> > #include <linux/timer.h>
> > #include <linux/mod_devicetable.h>
> > +//#include <linux/bitops.h>
> You added and commented it out?

> > #define NBITS(x) (((x)/BITS_PER_LONG)+1)
> > -#define BIT(x) (1UL<<((x)%BITS_PER_LONG))
> > +#undef BIT
> > +#define BIT(nr)        (1UL << ((nr) % BITS_PER_LONG))
> Why did you change x to nr? The other defines seems to use x.
just messed it up while testing
would clean it after we decide to add a new macro
& before i send the final version.

> > -#define BIT(x)         (1ul<<(x))
> > #define POW2(x)                (1ul<<(x))
> Maybe you can clean up POW2 as well (or define it as "#define POW2(x)
> BIT(x)")
yes
but want to go one step at a time
currently just  cleaning up places where BIT macro is explicitly defined
the implicit uses [replacing 1UL << (x)] will be handled in another patch series
"use BIT macro wherever appropriate"

>
> Also, it seems your mail-client swapped the tabs to spaces (aka not able
> to apply).
attaching the patch file
bear with me for the time being

-- 
Milind Arun Choudhary

Download attachment "BIT-macro-cleanup.patch" of type "application/octet-stream" (13734 bytes)