Re: [PATCH SERIES] untangle spinlock macros

[Donald Douwsma <donaldd@sgi.com>]

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