Re: Define __raw_read_lock etc for uniprocessor builds

[Joe Korty <joe.korty@ccur.com>]

On Tue, Jan 24, 2006 at 07:32:02PM +0100, Arjan van de Ven wrote:
> On Tue, 2006-01-24 at 13:29 -0500, Joe Korty wrote:
> > On Tue, Jan 24, 2006 at 06:17:12PM +0000, Christoph Hellwig wrote:
> > > On Tue, Jan 24, 2006 at 01:09:54PM -0500, Joe Korty wrote:
> > > > 
> > > > Make NOPed versions of __raw_read_lock and family available
> > > > under uniprocessor kernels.
> > > > 
> > > > Discovered when compiling a uniprocessor kernel with the
> > > > fusyn patch applied.
> > > > 
> > > > The standard kernel does not use __raw_read_lock etc
> > > > outside of spinlock.c, which may account for this bug
> > > > being undiscovered until now.
> > > 
> > > No one should call these directly.   Please fix your odd patch instead.
> > 
> > Actually the patch calls the _raw version which is #defined to the __raw
> > version.  So it is doing the correct thing.
> 
> no it's not, it has no business calling the _raw version either.

Nope.

1) The _raw_spin_lock family is used everywhere in the kernel.  Why the
arbitrary special rule for _raw_read_lock??????  It makes no sense.

2) The _raw versions are intended to be used in places where it is
known that preemption is already disabled, so that the overhead of
re-disabling/enabling it can be avoided.

Joe
--
"All the revision in the world will not save a bad first draft, for the
architecture of the thing comes, or fails to come, in the first conception,
and revision only affects the detail and ornament. -- T.E. Lawrence