Re: Linux 2.6.24-rc5 x86 architecture no longer Oopses...

[Andrew Morton]

On Fri, 21 Dec 2007 12:12:07 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > I'd suggest that we add a local_read_flags() along with 
> > local_save_flags(). Then I can merge the parts of the patch which 
> > don't get destroyed by ongoing churn and then we can come in and clean 
> > up the stragglers later.
> 
> ah, indeed.
> 
> like the patch below? (Only local_save_flags() should be used by drivers 
> - but i stuck in the other variants as well for completeness.)
> 
> 	Ingo
> 
> -------------------->
> Subject: migration helpers for local_save_flags => local_read_flags rename
> From: Ingo Molnar <mingo@xxxxxxx>
> 
> prepare for renaming of all local_save_flags variants to local_read_flags,
> via migration helpers, as suggested by Andrew Morton.
> 
> Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> ---
>  include/linux/irqflags.h |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> Index: linux-x86.q/include/linux/irqflags.h
> ===================================================================
> --- linux-x86.q.orig/include/linux/irqflags.h
> +++ linux-x86.q/include/linux/irqflags.h
> @@ -93,4 +93,13 @@
>  #define irqs_disabled_flags(flags)	raw_irqs_disabled_flags(flags)
>  #endif		/* CONFIG_X86 */
>  
> +/*
> + * Migration helpers - the proper API is the local_read_flags API.
> + * Will go away in v2.6.26.
> + */
> +#define local_save_flags		local_read_flags
> +#define __local_save_flags		__local_read_flags
> +#define raw_local_save_flags		raw_local_read_flags
> +#define __raw_local_save_flags		__raw_local_read_flags
> +

Looks good.  We also have local_irq_save(), raw_local_irq_save() and
__raw_local_irq_save() which might or might not disable interrupts.  (Do we
really need three flavours of these?)

I guess that people's understanding of spin_lock_irqsave() (note the
irqsave versus irq_save inconsistency) is sufficiently good for nobody to
get tripped up by local_irq_save().  But it's a poor name nonetheless.


It'd be nice to move away from macros too if poss?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/