Milind Arun Choudhary wrote:
why bitops.h? coz BIT qualifies for a "bitop"
& bitops.h is inclued by kernel.h, hence accessible from every part
of the tree without mucb efforts
I don't think there is anyone who objects to this
c>but it is not sutaible for those who want to go beyond this li
On Saturday 24 February 2007 07:59, Richard Knutsson wrote:
> Vojtech Pavlik wrote:
> > On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
> >
> >
> >> Is the reason for the modulo to put a bitmask larger then the variable
> >> into an array?
> >>
> >
> > The complementary L
On Saturday 24 February 2007 06:11, Vojtech Pavlik wrote:
> > The reason I don't like it with modulo is simply because it hides
> > potential bugs (when x is to big).
>
> That would be my only concern - losing compiler warnings.
>
I think most dangerous scenario is when both shift operands are
On 12:11 Sat 24 Feb , Vojtech Pavlik wrote:
>
> That would be my only concern - losing compiler warnings.
yes
see
I wanted a single BIT macro which can be used by the whole tree
was looking for a multipurpose one. found it in input.h
so i thought i will put it at a common place
why bitops.h
Vojtech Pavlik wrote:
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
Is the reason for the modulo to put a bitmask larger then the variable
into an array?
The complementary LONG() macro will tell you the index of an array of
longs where the bit should be set.
Thi
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
> >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 s
On Fri, Feb 23, 2007 at 01:44:41PM +0530, Milind Choudhary wrote:
> Hi all
> working towards the cleanup of BIT macro,
> I've added one to & cleaned some obvious users.
>
> include/linux/input.h also has a BIT macro
> which does a wrap
> so currently i've done something like
>
> +#undef BI
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
>
>> but mainly since it only enables wrapping of the long-type.
>
> I'd provde BIT and separate LLBIT for ones who re
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
>
>> but mainly since it only enables wrapping of the long-type.
>
> I'd provde BIT and separate LLBIT for ones who really need long long.
> P
Dmitry Torokhov wrote:
I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
but mainly since it only enables wrapping of the long-type.
I'd provde BIT and separate LLBIT for ones who really need long long.
People who intereseted in smaller than BITS_PER_LONG bitmaps sho
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> Milind Choudhary wrote:
>> > On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> >> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >> >
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Milind Choudhary wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >
>> > & make the whole input subsystem use it
>> > The change is huge,
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Milind Choudhary wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >
>> > & make the whole input subsystem use it
>> > The change is huge, more than 125 files usi
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
Milind Choudhary wrote:
Hi all
working towards the cleanup of BIT macro,
I've added one to & cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL << ((nr) % BITS_PER_LONG))
Is
Hi all
working towards the cleanup of BIT macro,
I've added one to & cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL << ((nr) % BITS_PER_LONG))
Is it advisible to move
19 matches
Mail list logo
