[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070608160840.GA11133@vino.hallyn.com>
Date: Fri, 8 Jun 2007 11:08:40 -0500
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Paul Menage <menage@...gle.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>, Paul Jackson <pj@....com>,
"Serge E. Hallyn" <serue@...ibm.com>, vatsa@...ibm.com,
ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
rohitseth@...gle.com, haveblue@...ibm.com, xemul@...ru, dev@...ru,
containers@...ts.osdl.org, devel@...nvz.org, ebiederm@...ssion.com,
mbligh@...gle.com, cpw@....com, svaidy@...ux.vnet.ibm.com,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
Quoting Paul Menage (menage@...gle.com):
> On 6/8/07, Serge E. Hallyn <serge@...lyn.com> wrote:
> >
> >Anyway the patch I sent is simple enough, and if users end up demanding
> >the ability to better deal with exclusive cpusets, the patch will be
> >simple enough to extend by changing cpuset_auto_setup(), so let's
> >stick with that patch since it's your preference (IIUC).
> >
>
> Sounds good to me, although I think my preference would be to extend
> the "create()" subsystem callback with a "struct task_struct
> *clone_task" parameter that indicates that clone_task is cloning its
> own container; a subsystem like cpusets that needs to do additional
> setup at that point could inherit settings either from the parent or
> from clone_task's container (or something else) as desired. (It could
> also do permission checking based on properties of clone_task, etc).
The problem is container_clone() doesn't call ->create explicitly, it
does vfs_mkdir. So we have no real way of passing in clone_task.
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists