xfs
[Top] [All Lists]

Re: [PATCH SERIES] untangle spinlock macros

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH SERIES] untangle spinlock macros
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Wed, 12 Sep 2007 11:06:53 +1000
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <46E6221E.803@sandeen.net>
References: <46E6221E.803@sandeen.net>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.4 (X11/20070604)
They look good to me.  There's still a few unused variables left over
but nothing we can't fix up.

Eric Sandeen wrote:
I have a series of patches at
http://sandeen.net/xfs-patches/patches-spinlock-unobfuscate.tar.bz2

to get rid of the macros upon macros hiding xfs' use of spinlocks, via
for example AIL_LOCK->mutex_spinlock->spin_lock.  This also gets rid of
the unused "cookie" variables declared via SPLDECL(s) and other
open-coded unsigned long s; declarations.

patches in the tarball, broken out by lock as requested a while
ago by dgc:

unwrap_AIL_LOCK
unwrap_LOG_LOCK
unwrap_GRANT_LOCK
unwrap_XFS_DQ_PINUNLOCK
unwrap_pagb_lock
unwrap_xfs_dabuf_global_lock
unwrap_mru_lock
unwrap_XFS_SB_LOCK
no_kt_lock
cleanup_lock_goop

Patches have comments/descriptions/signed-off lines in them.

By the end of the series, spin.h is almost empty, only spin_lock_init /
spinlock_destroy are left, and could maybe even be pulled out.... wasn't
sure how far to go.  Since the kernel has a mutex_destroy, I wonder if
spinlocks will ever get similar treatment... anyway....

I can post them to the list individually if preferred... though it's
fairly mechanical and not terribly interesting...

Thanks,
-Eric





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