Coming from a "simplify things" pov:
On Fri, Apr 06, 2007 at 04:32:24PM -0700, [EMAIL PROTECTED] wrote:
> struct container {
> unsigned long flags; /* "unsigned long" so bitops work */
>
> /*
> - * Count is atomic so can incr (fork) or decr (exit) without a lock.
> - */
> - atomic_t count; /* count tasks using this container */
> -
> - /*
> * We link our 'sibling' struct into our parent's 'children'.
> * Our children link their 'sibling' into our 'children'.
> */
> @@ -43,11 +106,13 @@ struct container {
> struct list_head children; /* my children */
>
> struct container *parent; /* my parent */
> - struct dentry *dentry; /* container fs entry */
> + struct dentry *dentry; /* container fs entry */
>
> -#ifdef CONFIG_CPUSETS
> - struct cpuset *cpuset;
> -#endif
> + /* Private pointers for each registered subsystem */
> + struct container_subsys_state *subsys[CONTAINER_SUBSYS_COUNT];
> +
> + struct containerfs_root *root;
Could this root pointer derived from dentry pointer
(cont->dentry->d_sb->s_fs_info)?
> + struct container *top_container;
and this as well?
cont->dentry->d_sb->s_fs_info->top_container
> };
So we have the foward subsys pointer array being stored in both
'struct container' and 'struct container_group' and reverse container pointer
stored in struct container_subsys_state. Can we reduce this pointer maze by:
struct container {
/* All shared stuff like flags, parent/child pointers etc */
..
struct container_group *my_group;
}
The forward mapping from 'struct container' to subsys objects is made via
'my_group'. This also lets 'struct container' be a placeholder strictly for
shared state.
On further thoughts, perhaps even my_group can be avoided by having:
dentry->d_fsdata point to my_group
and cont->dentry->d_fsdata will point to my_group which we wanted to store
above.
I don't see distinct adv of doing this, but I suspect it will simplify
the structure relationship (and code) a bit.
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
