LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Richard Knutsson <ricknu-0@student.ltu.se>
To: Milind Choudhary <milindchoudhary@gmail.com>
Cc: kernel-janitors@lists.osdl.org, linux-kernel@vger.kernel.org,
	dmitry.torokhov@gmail.com, 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 15:10:54 +0100	[thread overview]
Message-ID: <45DEF5EE.4030002@student.ltu.se> (raw)
In-Reply-To: <3b44d3fb0702230215o2fbd5a3y25729e481a447149@mail.gmail.com>

Milind Choudhary wrote:
> On 2/23/07, Richard Knutsson <ricknu-0@student.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
You 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.
>> > -#define BIT(i)         (1UL << ((i)&(__NFDBITS-1)))
>> Are you sure you can just delete this one?
> yes...no users in this file
Ok
>> > -#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"
Sounds good
>
>>
>> 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
>
No problem :)
It is of course always a good idea to send the patches to yourself and 
then trying to apply that patch to see it is alright. But sometimes you 
can't get the mailer working, then sendpatchset can be of interest:
http://www.speakeasy.org/~pj99/sgi/sendpatchset

Richard Knutsson


  reply	other threads:[~2007-02-23 14:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3b44d3fb0702222056k1d2a9b57q69a3555a09a9058e@mail.gmail.com>
2007-02-23  8:14 ` Milind Choudhary
2007-02-23  8:56   ` Richard Knutsson
2007-02-23 10:15     ` Milind Choudhary
2007-02-23 14:10       ` Richard Knutsson [this message]
2007-02-23 14:57         ` Dmitry Torokhov
2007-02-23 16:08           ` Richard Knutsson
2007-02-23 17:05             ` Dmitry Torokhov
2007-02-23 18:15               ` Richard Knutsson
2007-02-23 18:37                 ` Dmitry Torokhov
2007-02-23 19:11                   ` Richard Knutsson
2007-02-23 21:58                     ` Dmitry Torokhov
2007-02-23 22:43                       ` Richard Knutsson
2007-02-24 11:11                         ` Vojtech Pavlik
2007-02-24 12:59                           ` Richard Knutsson
2007-02-25  3:39                             ` Dmitry Torokhov
2007-02-24 19:11                           ` Milind Arun Choudhary
2007-02-25 15:45                             ` Richard Knutsson
2007-02-25  3:37                           ` Dmitry Torokhov
2007-02-24 10:46   ` Vojtech Pavlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DEF5EE.4030002@student.ltu.se \
    --to=ricknu-0@student.ltu.se \
    --cc=dmitry.torokhov@gmail.com \
    --cc=kernel-janitors@lists.osdl.org \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-joystick@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=milindchoudhary@gmail.com \
    --subject='Re: [KJ][RFC][PATCH] BIT macro cleanup' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).