On 11/03/2012 09:38 AM, Tejun Heo wrote: > Currently, there's no way for a controller to find out whether a new > cgroup finished all ->create() allocatinos successfully and is > considered "live" by cgroup. > > This becomes a problem later when we add generic descendants walking > to cgroup which can be used by controllers as controllers don't have a > synchronization point where it can synchronize against new cgroups > appearing in such walks. > > This patch adds ->post_create(). It's called after all ->create() > succeeded and the cgroup is linked into the generic cgroup hierarchy. > This plays the counterpart of ->pre_destroy(). > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> > Cc: Glauber Costa <glommer@xxxxxxxxxxxxx> Tejun, If we do it this way, we end up with two callbacks that are called after create: post_clone and post_create. I myself prefer the approach I took, that convert post_clone into post_create, and would prefer if you would pick that up. For me, post_clone is totally a glitch that should not exist. Merging this with post_create gives the following semantics: * A while after cgroup creation, you will get a callback. In that callback, you do whatever initialization you may need that you could not in create. Why is reacting to a flag being set any different? -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
