[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071221123113.GA19136@elte.hu>
Date: Fri, 21 Dec 2007 13:31:13 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: trond.myklebust@....uio.no, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.24-rc5 x86 architecture no longer Oopses...
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> > +/*
> > + * 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?)
all disable interrupts. All the raw_ and __ APIs are for internal use
only, they should _not_ be used by anything but directly lockdep related
code.
> 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.
yeah, but it's the historic name that stems from the old cli() API that
had "global scope". I guess these days people know that irq-disabling is
a CPU-local business, not a global thing? I cannot think of any good
alternative name though.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists