Re: [PATCH SERIES] untangle spinlock macros

Donald Douwsma
2007-09-12T01:51:20Z

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.
>

Hi Eric,

> unwrap_AIL_LOCK
Here you change the comment to use the descriptive name

- * We must not be holding the AIL_LOCK at this point. Calling incore() to
- * search the buffer cache can be a time consuming thing, and AIL_LOCK is a
+ * We must not be holding the AIL lock at this point. Calling incore() to
+ * search the buffer cache can be a time consuming thing, and AIL lock is a
* spinlock.
*/

> 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
But here you use the name of the lock variable.

/*
- * We actually don't have to acquire the SB_LOCK at all.
+ * We actually don't have to acquire the m_sb_lock at all.
* This can only be called from mount, and that's single threaded. XXX
*/

> 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....
So the only things left in spin.h are the spinlock headers and

#define spinlock_init(lock, name) spin_lock_init(lock)
#define spinlock_destroy(lock)

I cant se why we need these abstractions. Should we nuke the whole file and
add the spinlock headers elsewhere?

Don