[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC735A2.4040400@parallels.com>
Date: Thu, 31 May 2012 13:10:58 +0400
From: Glauber Costa <glommer@...allels.com>
To: <jeff.liu@...cle.com>
CC: <containers@...ts.linux-foundation.org>, <cgroups@...r.kernel.org>,
<jack@...e.cz>, <daniel.lezcano@...e.fr>, <tytso@....edu>,
<bpm@....com>, <chris.mason@...cle.com>, <hch@...radead.org>,
<christopher.jones@...cle.com>, <david@...morbit.com>,
<tinguely@....com>, <tm@....ma>, <linux-ext4@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 04/12] container quota: introduce container disk quota
data header file.
> +
> +/* Operations for quota control */
> +struct ns_quotactl_ops {
> + int (*quota_on)(struct mnt_namespace *, int);
> + int (*quota_off)(struct mnt_namespace *, int);
> + int (*get_info)(struct mnt_namespace *, int, struct if_dqinfo *);
> + int (*set_info)(struct mnt_namespace *, int, struct if_dqinfo *);
> + int (*get_dqblk)(struct mnt_namespace *, int, qid_t,
> + struct fs_disk_quota *);
> + int (*set_dqblk)(struct mnt_namespace *, int, qid_t,
> + struct fs_disk_quota *);
> +};
> +
That is quite bad. Just have the same signature. Which namespace you
belong to can *always* be derived from the calling process, you should
never need to specify that in any interface. It is of course fine to do
that in functions internal to the kernel, but not this.
You should rethink the whole ns_quota thing. Some of it I believe will
have to stay, I doubt we'll be able to be completely transparent. But
the core of your changes have to be making sure a hierarchical walk over
the valid quotas work well, finding out what are those valid quotas, etc.
The interface should be kept as unchanged as possible, and this can be
achieved by things like automatic discover of the current namespace, and
pre-operational container setup for the relevant files.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists