[PATCH] xfs: kill xfs_qmops

[Eric Sandeen]

Christoph Hellwig wrote:
...

> never, but that's a bug because the loop should now start at 0.  Looks
> like out quota testing in xfsqa still isn't that good or the first
> inode is always already attached in normal operation (probably the latter).
> 
> Updated patch below:
> 
> 
> Subject: xfs: kill xfs_qmops
> From: Christoph Hellwig <hch at lst.de>
> 
> Kill the quota ops function vector and replace it with direct calls or
> stubs in the CONFIG_XFS_QUOTA=n case.
> 
> Make sure we check XFS_IS_QUOTA_RUNNING in the right spots.  We can remove
> the number of those checks because the XFS_TRANS_DQ_DIRTY flag can't be set
> otherwise.
> 
> This brings us back closer to the way this code worked in IRIX and earlier
> Linux versions, but we keep a lot of the more useful factoring of common
> code.
> 
> Eventually we should also kill xfs_qm_bhv.c, but that's left for a later
> patch.
> 
> Reduces the size of the source code by about 250 lines and the size of
> XFS module by about 1.5 kilobytes with quotas enabled:
> 
>    text	   data	    bss	    dec	    hex	filename
>  615957	   2960	   3848	 622765	  980ad	fs/xfs/xfs.o
>  617231	   3152	   3848	 624231	  98667	fs/xfs/xfs.o.old
> 
> 
> Fallout:
> 
>  - xfs_qm_dqattach is split into xfs_qm_dqattach_locked which expects
>    the inode locked and xfs_qm_dqattach which does the locking around it,
>    thus removing XFS_QMOPT_ILOCKED.
> 
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> 

Looks better to me now, thanks.  Though worrisome that quota doesn't
seem well-tested in xfsqa, as you said... but as far as I can tell seems
ok now.  Have arekm test it a bit too ;)

Reviewed-by: Eric Sandeen <sandeen at sandeen.net>