Mailing List Archive

On Friday 06 January 2006 15:05, Christian Limpach wrote:
> On Fri, Jan 06, 2006 at 12:28:33PM +0100, Jan Beulich wrote:
> > I realize that it was your preference to not split the i386 and x86-64
> > variants, as I had suggested with my patch. However, in course of
> > undoing that patch the bug fixes got dropped, too. Was that
> > intentional?
>
> I dropped the changes where instead of using =m, you suggested using +m.
> The original Linux' bitops.h uses =m and using +m doesn't really make
> a difference in this case.

It's actually using +m in the post 2.6.15 queue.

-Andi

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 06.01.06 15:05:12
>>>
>On Fri, Jan 06, 2006 at 12:28:33PM +0100, Jan Beulich wrote:
>> I realize that it was your preference to not split the i386 and
x86-64
>> variants, as I had suggested with my patch. However, in course of
>> undoing that patch the bug fixes got dropped, too. Was that
>> intentional?
>
>I dropped the changes where instead of using =m, you suggested using
+m.
>The original Linux' bitops.h uses =m and using +m doesn't really make
>a difference in this case.

As far as I know, there actually is a patch in Andi's queue to change
that. I just thought it would be best to incorporate this correction now
instead of waiting for (and then perhaps forgetting about) the mainline
change.

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Fri, Jan 06, 2006 at 03:39:15PM +0100, Jan Beulich wrote:
> >>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 06.01.06 15:05:12
> >>>
> >On Fri, Jan 06, 2006 at 12:28:33PM +0100, Jan Beulich wrote:
> >> I realize that it was your preference to not split the i386 and
> x86-64
> >> variants, as I had suggested with my patch. However, in course of
> >> undoing that patch the bug fixes got dropped, too. Was that
> >> intentional?
> >
> >I dropped the changes where instead of using =m, you suggested using
> +m.
> >The original Linux' bitops.h uses =m and using +m doesn't really make
> >a difference in this case.
>
> As far as I know, there actually is a patch in Andi's queue to change
> that. I just thought it would be best to incorporate this correction now
> instead of waiting for (and then perhaps forgetting about) the mainline
> change.

Yeah, in that case it makes sense.

christian


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

So AFAIK synch_bitops.h is equivilent to bitops.h with #defined
CONFIG_SMP

Can't we use this somehow to reduce the amount of repeated code?

On Jan 6, 2006, at 9:05 AM, Christian Limpach wrote:

> On Fri, Jan 06, 2006 at 12:28:33PM +0100, Jan Beulich wrote:
>> I realize that it was your preference to not split the i386 and
>> x86-64
>> variants, as I had suggested with my patch. However, in course of
>> undoing that patch the bug fixes got dropped, too. Was that
>> intentional?
>
> I dropped the changes where instead of using =m, you suggested
> using +m.
> The original Linux' bitops.h uses =m and using +m doesn't really make
> a difference in this case.
>
> christian
>
>
> _______________________________________________
> Xen-merge mailing list
> Xen-merge@lists.xensource.com
> http://lists.xensource.com/xen-merge
>

-JX
--
"I got an idea, an idea so smart my head would explode if I even
began to know what I was talking about." -- Peter Griffin (Family
Guy)




_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>So AFAIK synch_bitops.h is equivilent to bitops.h with #defined
>CONFIG_SMP
>
>Can't we use this somehow to reduce the amount of repeated code?

Sure, this would be possible. But would anyone like the to be added
conditionals (bitops.h has many more operations defined than
synch_bitops.h, and these would need to be disabled)? And similarly for
the need to alter the function names? At least from my experience,
adding a new file will have less resistance than cluttering an existing
one...

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

One question that comes to mind, is that in a para-virtualized
environment does CONFIG_SMP cost you anything?
On PPC and the IBM hypervisor we have found that is does not.

On Jan 6, 2006, at 11:06 AM, Jan Beulich wrote:

>> So AFAIK synch_bitops.h is equivilent to bitops.h with #defined
>> CONFIG_SMP
>>
>> Can't we use this somehow to reduce the amount of repeated code?
>
> Sure, this would be possible. But would anyone like the to be added
> conditionals

Not conditional but some CPP majik.
hmm, not a fan of clutter, but maybe some CPP magik?

this is what we have for powerpc:
#ifdef CONFIG_SMP
#include <asm/bitops.h>

#define synch_change_bit(a,b) change_bit(a,(unsigned long *)b)
#define synch_clear_bit(a,b) clear_bit(a,(unsigned long *)b)
#define synch_cmpxchg(a,b) cmpxchg(a,(unsigned long *)b)
#define synch_const_test_bit(a,b) const_test_bit(a,(unsigned long *)b)
#define synch_set_bit(a,b) set_bit(a,(unsigned long *)b)
#define synch_test_and_set_bit(a,b) test_and_set_bit(a,(unsigned long
*)b)
#define synch_test_and_change_bit(a,b) test_and_change_bit(a,
(unsigned long *)b)
#define synch_test_and_clear_bit(a,b) test_and_clear_bit(a,(unsigned
long *)b)
#define synch_test_bit(a,b) test_bit(a,(unsigned long *)b)
#define synch_var_test_bit(a,b) var_test_bit(a,(unsigned long *)b)

#else
#error "this only works for CONFIG_SMP"
#endif

now for the !CONFIG_SMP one could easily imagine some CPP majik to
solve that.

-JX
--
"I got an idea, an idea so smart my head would explode if I even
began to know what I was talking about." -- Peter Griffin (Family
Guy)




_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge