On Mon, 2006-03-06 at 17:57 -0800, Chris Wright wrote:
> * Dave Hansen ([email protected]) wrote:
> > --- work/include/linux/init_task.h~sysvmsg-container 2006-03-06 15:41:56.000000000 -0800
> > +++ work-dave/include/linux/init_task.h 2006-03-06 15:41:56.000000000 -0800
> > @@ -2,6 +2,7 @@
> > #define _LINUX__INIT_TASK_H
> >
> > #include <linux/file.h>
> > +#include <linux/ipc.h>
> > #include <linux/rcupdate.h>
> >
> > #define INIT_FDTABLE \
>
> missing INIT_IPC_CONTEXT type of macro?
Yeah, I was doing something like that at first. But, I decided to
dynamically allocate it, much like it will have to be done when we have
_real_ namespaces for it. That means that we can't actually initialize
it at init_task.h time.
> > diff -puN include/linux/sched.h~sysvmsg-container include/linux/sched.h
> > --- work/include/linux/sched.h~sysvmsg-container 2006-03-06 15:41:56.000000000 -0800
> > +++ work-dave/include/linux/sched.h 2006-03-06 15:41:56.000000000 -0800
> > @@ -793,6 +793,7 @@ struct task_struct {
> > int link_count, total_link_count;
> > /* ipc stuff */
> > struct sysv_sem sysvsem;
> > + struct ipc_context *ipc_context;
>
> how does this propagate on clone (presently it's just side-effect of
> dup_task_struct starting from init_task, with no dynamic lifetime),
> how is it meant to be changed?
Some interface later down the road. You caught me a bit early in the
cycle.
> > -void __init msg_init (void)
> > +void __init msg_init (struct ipc_msg_context *context)
> > {
> > - ipc_init_ids(&msg_ids,msg_ctlmni);
> > + ipc_init_ids(&context->ids,msg_ctlmni);
> > ipc_init_proc_interface("sysvipc/msg",
> > " key msqid perms cbytes qnum lspid lrpid uid gid cuid cgid stime rtime ctime\n",
> > - &msg_ids,
> > + &context->ids,
> > sysvipc_msg_proc_show);
>
> Does that mean /proc interface only gets init_task context?
> Along those lines, I think now ipcs -a is incomplete from admin
> perspective. Suppose that's a feature from the container/vserver
> POV.
It will get context from the current task, which means the current
container. We haven't quite decided how these things will be (or if
they need to be) aggregated on a a system-wide basis.
> > --- work/ipc/util.h~sysvmsg-container 2006-03-06 15:41:56.000000000 -0800
> > +++ work-dave/ipc/util.h 2006-03-06 15:41:56.000000000 -0800
> > @@ -12,7 +12,7 @@
> > #define SEQ_MULTIPLIER (IPCMNI)
> >
> > void sem_init (void);
> > -void msg_init (void);
> > +void msg_init (struct ipc_msg_context *context);
> > void shm_init (void);
> >
> > struct ipc_id_ary {
> > @@ -30,6 +30,18 @@ struct ipc_ids {
> > struct ipc_id_ary* entries;
> > };
> >
> > +struct ipc_msg_context {
> > + atomic_t bytes;
> > + atomic_t hdrs;
> > +
> > + struct ipc_ids ids;
> > + struct kref count;
> > +};
> > +
> > +struct ipc_context {
> > + struct ipc_msg_context msg;
> > +};
>
> This looks a little suspect. ref count embedded in embedded object.
> My first thought was, sem and shared memory would introduce same, and
> now we'd have 3 independent refounts for top level object. However,
> it's not used, and doesn't appear to be mirrored in the sem and shared
> mem contexts. Perhaps it is just a leftover?
Yeah, I have the feeling that it used to be an atomic_t, and got
converted over to a kref a bit needlessly. I'll investigate more when I
spin the patches again.
-- Dave
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
