xfs
[Top] [All Lists]

Re: [PATCH 1/3] quota: Add a new quotactl command Q_XGETQSTATV

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/3] quota: Add a new quotactl command Q_XGETQSTATV
From: Jan Kara <jack@xxxxxxx>
Date: Wed, 21 Aug 2013 15:01:52 +0200
Cc: Chandra Seetharaman <sekharan@xxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, Steven Whitehouse <swhiteho@xxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Abhijith Das <adas@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130821064357.GA8822@xxxxxxxxxxxxx>
References: <1375828029-26360-1-git-send-email-sekharan@xxxxxxxxxx> <1375828029-26360-2-git-send-email-sekharan@xxxxxxxxxx> <20130821064357.GA8822@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue 20-08-13 23:43:57, Christoph Hellwig wrote:
> Sorry for being late to the game, but I don not like the in-kernel
> interface here at all.  Given that Q_XGETQSTATV is a strict superset
> of Q_XGETQSTAT there is no need for the second method - just always
> fill out the larger in-kernel structure and only copy the smaller
> information to userspace for the Q_XGETSTAT case.  That keeps the amount
> of code required in the implementations of the methods low and follows
> the model used elsewhere in the kernel (e.g. stat and statfs)
  Well, the trouble is with gquota vs pquota - previously we report in
qs_gquota field either group quotas or project quotas depending on what is
turned on. Generic quota code doesn't know this so xfs get_xstatev() would
have to recognize whether it is being called from the old Q_XGETSTAT
quotactl or from the new Q_XGETSTATV quotactl to know where to fill in
project quotas. And at that point you somewhat loose the elegancy of using
one interface - we could set qs_version to some special value so that
.get_xstatev() recognizes this and does the magic but that doesn't seem very
different from the extra call...

Some duplication could be certainly avoided within XFS itself.

                                                                Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR

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