Re: [PATCH] Define EFLAGS_IF

2007-04-08 Thread Rusty Russell
On Fri, 2007-04-06 at 08:39 -0700, H. Peter Anvin wrote: > I will, unless Rusty does, first. No desire to step on each other. Oh no, please, after you! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [PATCH] Define EFLAGS_IF

2007-04-08 Thread Rusty Russell
On Fri, 2007-04-06 at 08:39 -0700, H. Peter Anvin wrote: I will, unless Rusty does, first. No desire to step on each other. Oh no, please, after you! Rusty. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [PATCH] Define EFLAGS_IF

2007-04-06 Thread H. Peter Anvin
Andi Kleen wrote: On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote: Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added

Re: [PATCH] Define EFLAGS_IF

2007-04-06 Thread Andi Kleen
On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote: > Andi Kleen wrote: > > > >No processor.h is such a hodgepodge of unrelated stuff that any > >splitting up is a good thing. > > > > Fair enough. However, I'd still like to see the X86_CR* constants > moved, too (and constants added

Re: [PATCH] Define EFLAGS_IF

2007-04-06 Thread Andi Kleen
On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote: Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added for at

Re: [PATCH] Define EFLAGS_IF

2007-04-06 Thread H. Peter Anvin
Andi Kleen wrote: On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote: Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Rusty Russell
On Thu, 2007-04-05 at 18:06 -0700, H. Peter Anvin wrote: > Andi Kleen wrote: > > > > No processor.h is such a hodgepodge of unrelated stuff that any > > splitting up is a good thing. > > > > Fair enough. However, I'd still like to see the X86_CR* constants > moved, too (and constants added

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added for at least CR0 as well.) -hpa - To unsubscribe from this list: send

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Andi Kleen
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote: > Jeremy Fitzhardinge wrote: > > > >That patch got dropped, and replaced by one which pulled all the flags > >definitions out of > > > > Saw that a little too late :) > > In general, it would be nice if the various CPU constants

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Jeremy Fitzhardinge wrote: That patch got dropped, and replaced by one which pulled all the flags definitions out of Saw that a little too late :) In general, it would be nice if the various CPU constants were all defined in one place, so I'd rather suggest protecting the appropriate

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Jeremy Fitzhardinge
H. Peter Anvin wrote: > Rusty Russell wrote: > >> There is now more than one place where we use the fact that bit 9 of >> eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it >> 512 so it can be used in asm, too. >> > > How about defining all the other EFLAGS in one

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Rusty Russell wrote: There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. How about defining all the other EFLAGS in one place? -hpa - To unsubscribe from this

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Rusty Russell wrote: There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. How about defining all the other EFLAGS in one place? -hpa - To unsubscribe from this

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Jeremy Fitzhardinge
H. Peter Anvin wrote: Rusty Russell wrote: There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. How about defining all the other EFLAGS in one place? That

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Jeremy Fitzhardinge wrote: That patch got dropped, and replaced by one which pulled all the flags definitions out of asm/processor.h Saw that a little too late :) In general, it would be nice if the various CPU constants were all defined in one place, so I'd rather suggest protecting the

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Andi Kleen
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote: Jeremy Fitzhardinge wrote: That patch got dropped, and replaced by one which pulled all the flags definitions out of asm/processor.h Saw that a little too late :) In general, it would be nice if the various CPU constants

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread H. Peter Anvin
Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added for at least CR0 as well.) -hpa - To unsubscribe from this list: send

Re: [PATCH] Define EFLAGS_IF

2007-04-05 Thread Rusty Russell
On Thu, 2007-04-05 at 18:06 -0700, H. Peter Anvin wrote: Andi Kleen wrote: No processor.h is such a hodgepodge of unrelated stuff that any splitting up is a good thing. Fair enough. However, I'd still like to see the X86_CR* constants moved, too (and constants added for at least

Re: [PATCH] Define EFLAGS_IF

2007-03-21 Thread Rusty Russell
On Thu, 2007-03-22 at 14:16 +1100, Rusty Russell wrote: > There is now more than one place where we use the fact that bit 9 of > eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it > 512 so it can be used in asm, too. Belay this: there's a X86_EFLAGS_IF in asm/processor.h which

[PATCH] Define EFLAGS_IF

2007-03-21 Thread Rusty Russell
There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- a/arch/i386/lguest/lguest.c +++ b/arch/i386/lguest/lguest.c @@

[PATCH] Define EFLAGS_IF

2007-03-21 Thread Rusty Russell
There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. Signed-off-by: Rusty Russell [EMAIL PROTECTED] --- a/arch/i386/lguest/lguest.c +++ b/arch/i386/lguest/lguest.c @@ -107,9

Re: [PATCH] Define EFLAGS_IF

2007-03-21 Thread Rusty Russell
On Thu, 2007-03-22 at 14:16 +1100, Rusty Russell wrote: There is now more than one place where we use the fact that bit 9 of eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it 512 so it can be used in asm, too. Belay this: there's a X86_EFLAGS_IF in asm/processor.h which we