On 05/31/2012 05:10 PM, Glauber Costa wrote:
>> +
>> +/* 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.
Exactly, "struct mnt_namespace" should not be presented at any quota
operation interface, retrieve it through current->nsproxy->mnt_ns should
be fine.
> 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.
Thanks for teaching me that, let me try to refactor ns_quota to make
the change as little as possible.
-Jeff
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
