On 5/1/07, Balbir Singh <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > This patch adds the main containers framework - the container > > filesystem, and the basic structures for tracking membership and > > associating subsystem state objects to tasks. > > [snip] > > > +*** notify_on_release is disabled in the current patch set. It may be > > +*** reactivated in a future patch in a less-intrusive manner > > + > > Won't this break user space tools for cpusets?
Yes, so it's a must-fix before this gets anywhere near a real distribution. > > [snip] > > > +See kernel/container.c for more details. > > + > > +Subsystems can take/release the container_mutex via the functions > > +container_lock()/container_unlock(), and can > > +take/release the callback_mutex via the functions > > +container_lock()/container_unlock(). > > + > > Hmm.. looks like a documentation error. Both mutex's are obtained through > container_lock/container_unlock ? The second half of that sentence is obsolete and should have been deleted. > > > +Accessing a task's container pointer may be done in the following ways: > > +- while holding container_mutex > > +- while holding the task's alloc_lock (via task_lock()) > > +- inside an rcu_read_lock() section via rcu_dereference() > > + > > container_mutex() and task_lock() can be used for changing the pointer? No, these are all for read operations. (Actually, this is a bit of documentation that's bit-rotted - there's no longer a per-task "container" pointer). I'll update this. For write operations, only the container system should be modifying those pointers (under the protection of both container_mutex and alloc_lock). > > We needed the equivalent of container_remove_file() to be called > if container_add_file() failed. > Yes, this is some incomplete behaviour that I inherited from cpusets. Needs tidying up. > > Can't we derive the top_container from containerfs_root? Yes, we could for the cost of an extra dereference. Not sure it's a big deal either way. > > + ssize_t (*read) (struct container *cont, struct cftype *cft, > > + struct file *file, > > + char __user *buf, size_t nbytes, loff_t *ppos); > > + u64 (*read_uint) (struct container *cont, struct cftype *cft); > > Is this a new callback, a specialization of the read() callback? Yes. It's to simplify the common case of reporting a number in a control file. (Not yet well documented :-( ) Paul ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
