xfs
[Top] [All Lists]

Re: TAKE - Move XFS out of the interrupt disabling game

To: Stephen Lord <lord@xxxxxxx>
Subject: Re: TAKE - Move XFS out of the interrupt disabling game
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 24 May 2002 13:34:52 +0100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <1022242835.1499.10.camel@snafu>; from lord@sgi.com on Fri, May 24, 2002 at 07:20:34AM -0500
References: <200205231900.g4NJ0Fn06774@jen.americas.sgi.com> <20020524103937.A7333@infradead.org> <1022241156.1136.3.camel@snafu> <20020524131016.A10604@infradead.org> <1022242835.1499.10.camel@snafu>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
On Fri, May 24, 2002 at 07:20:34AM -0500, Stephen Lord wrote:
> lock_t == spinlock
> 
> The places where we define something as a spinlock directly were done
> for linux. The original irix definitions use lock_t.

That's not what I meant.  In fs/xfs/support/spin.h there is a mapping of
the Linux spinlock_t to the IRIX lock_t and also some mapping of the
operations which are named differently.  It looks to me this is the
basic IRIX spinlock primitive (unlike the SVR4.2MP lock_t which is a
rather highlevel lock), still there is mutex_spinlock/mutex_spinunlock
in fs/xfs/support/mutex.h that operate on Linux spinlock_t but seem to
emulate some IRIX primitives as there would be no other reason to have them.

Somehow I seems to miss the point of mutex_spinlock/mutex_spinunlock..

> They are I think accessible on the web already along with a lot of other
> stuff:
> 
>       http://techpubs.sgi.com/library/tpl/cgi-bin/init.cgi

Hmm, this doesn't even mention mutex* :P


<Prev in Thread] Current Thread [Next in Thread>