public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v7 0/5] xfs: Allow pquota and gquota to be used together
Date: Mon, 25 Mar 2013 10:14:35 +1100	[thread overview]
Message-ID: <20130324231435.GG6369@dastard> (raw)
In-Reply-To: <1363964446.27672.14.camel@chandra-dt.ibm.com>

On Fri, Mar 22, 2013 at 10:00:46AM -0500, Chandra Seetharaman wrote:
> Sure. I will look at your CRC patchset and see what changes are needed
> to mine.
> 
> Meantime, you can answer my dilemma with the change in fs_quota_stat
> (see patch 4).
> 
> As per your suggestion, I changed the data structure, to include pads at
> relevant places in the data structure, which also means that the new
> modified structure is not compatible with older user space code. 
> 
> So, I created a copy of the older structure (fs_quota_stat_v1) and used
> that if the user space request has older structure. So, now the new
> kernel code is backward compatible with the old (already running) user
> space code. All is well till now....
> 
> Now, I make the changes to the user space code so as to use the new
> fs_quota_stat. Since the data structure has changed, the new user space
> code will not work with the old kernel code.

The issue that the userspace code has to handle is that old kernels
decide the version of the structure, not userspace. i.e. the
version number is an output parameter, not an input parameter. Hence
on old kernels we have to detect the version after the call rather
than assume the kernel treated the version as an input...

> This is where I have the dilemma. 
> 
> 1. Leave the user space code to work only with the newer version,
> breaking the compatibility with the older kernel (with an error
> message).
>    or
> 2. Read the superblock, and if pquotino is _not_ present conclude older
> version of fs_quota_stat would suffice for getting quota information
> from kernel (note that this will work properly with newer kernel code
> too), and use the older version of fs_quota_stat_v1 for quotactl.
>    or
> 3. Any other clever way ? :)

Because the version is only an output field for old kernels, the
userspace code should be able to handle it like this:

	struct fs_quota_stat fqs;

	ASSERT(sizeof(struct fs_quota_stat) >= sizeof(struct fs_quota_stat_v1));

	memset(&fqs, 0, sizeof(fqs));
	fqs.version = FS_QSTAT_VERSION_2;
	error = quotactl(...., &fqs);

	if (fqs.version == FS_QSTAT_VERSION) {
		struct fs_quota_stat_v1 *fqsv1 = &fqs;

		/* process as version 1 */
		.....
		return error;
	}

	/* process as version 2 */
	.....
	return error;

However, with the version field in the same place for both
structures, userspace can read the version number after the call and
determine the correct structure type for the information returned by
the kernel...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-24 23:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 21:52 [PATCH v7 0/5] xfs: Allow pquota and gquota to be used together Chandra Seetharaman
2013-03-21 21:52 ` [PATCH v7 1/5] xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD Chandra Seetharaman
2013-03-21 21:52 ` [PATCH v7 2/5] xfs: Add pquota fields and use them at appropriate places Chandra Seetharaman
2013-03-21 21:52 ` [PATCH v7 3/5] xfs: Add pquotaino to on-disk super block Chandra Seetharaman
2013-03-21 21:52 ` [PATCH v7 4/5] xfs: Add proper versioning support to fs_quota_stat Chandra Seetharaman
2013-03-21 21:52 ` [PATCH v7 5/5] xfs: Use the new qs_pquota field in fs_quota_stat for Q_XGETQSTAT Chandra Seetharaman
2013-03-22  2:02 ` [PATCH v7 0/5] xfs: Allow pquota and gquota to be used together Dave Chinner
2013-03-22 15:00   ` Chandra Seetharaman
2013-03-24 23:14     ` Dave Chinner [this message]
2013-03-25 20:08       ` Chandra Seetharaman
2013-04-29 17:28   ` Chandra Seetharaman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130324231435.GG6369@dastard \
    --to=david@fromorbit.com \
    --cc=sekharan@us.ibm.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox