Thread (2 messages) 2 messages, 2 authors, 2012-08-28

Re: [PATCH] userns: Add basic quota support v2

From: Jan Kara <jack@suse.cz>
Date: 2012-08-28 17:51:01
Also in: linux-fsdevel, lkml

On Tue 28-08-12 10:34:04, Eric W. Biederman wrote:
Jan Kara [off-list ref] writes:
quoted
quoted
+		return -EINVAL;
+	ret = sb->s_qcop->get_dqblk(sb, qown, &fdq);
 	if (ret)
 		return ret;
 	copy_to_if_dqblk(&idq, &fdq);
...
quoted
+static inline u32 from_qown(struct user_namespace *user_ns, struct qown qown)
+{
+	switch (qown.type) {
+	case USRQUOTA:
+		return from_kuid(user_ns, qown.uid);
+	case GRPQUOTA:
+		return from_kgid(user_ns, qown.gid);
+	case XQM_PRJQUOTA:
+		return (user_ns == &init_user_ns) ? qown.prj : -1;
+	default:
+		BUG();
+	}
+}
  I would like a bit more if the function somehow expressed in its name
that it returns id. id_from_qown() might be a bit too long given how often
it is used. qown2id() would be OK but it would be inconsistent with how
names of other functions you've added are formed. So I'm somewhat
undecided...
The qown vs id distinction bothers me a little bit.

I almost want to name it struct kid, and the functions make_kid,
from_kid etc.  Where the emphasis is that we are transforming in and out
of the kernel internal form.  I don't really like make_kid because id as
a base name seems to generic and it barely tells you it is.  Perhaps
make_kqid.  Where we call the quota ids and qid for short?

I am a little uncomfortable calling them kqids because the userspace
code also places format_ids in a plain qid_t.  But make_kqid and
from_kqid seems the best alternate set of names I can come up with.
  OK, these would seem reasonable to me.

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help