On Fri, 2002-05-24 at 07:10, Christoph Hellwig wrote:
> On Fri, May 24, 2002 at 06:52:35AM -0500, Stephen Lord wrote:
> > Thanks, you are correct (again), I flipped all this code over to
> > just use spin_lock and spin_unlock. I suspect we can do away with
> > most of this vfs lock code on linux actually, just a matter of thinking
> > about it hard enough. It is there on Irix to prevent things happening
> > to the filesystem (like unmount) during certain operations - and to
> > make those operations exclusive with unmount.
>
> On Linux makeing vfs_busycnt an atomic_t and using bitops on vfs_flag
> should allow getting rid of it. I just wonder whether that is wanted due
> to IRIX compatiblity.
and the v_flags field in the vnode too actually - just looked at that
one and decided we could do that, but not this morning.
>
> > > The name suggests that it is used in IRIX to spin on a mutex_t on
> > > contention, but that means it's argument is already very different on
> > > Linux. Given that fact I wonder why it is still kept for the few user.
> >
> > I think the naming comes from it being a spinlock based mutual exclusion
> > primitive, not that it took a mutex. It is spinlock based on Irix too.
>
> What's the difference to the lock_t based operations then? Maybe SGI could
lock_t == spinlock
The places where we define something as a spinlock directly were done
for linux. The original irix definitions use lock_t.
> submit the IRIX manpages to Wolfram Schneider <wosch@xxxxxxxxxxx>, so they
> are publically accessible at the FreeBSD hypertext manpages website
> (http://www.freebsd.org/cgi/man.cgi) like many other Unix versions'Unix
> versions'
> manpges.
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
Steve
|