From: Dave Hansen <haveblue@us.ibm.com>
To: Kirill Korotaev <dev@sw.ru>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
xemul@sw.ru, ebiederm@xmission.com, linux-kernel@vger.kernel.org,
herbert@13thfloor.at, devel@openvz.org, serue@us.ibm.com,
sam@vilain.net
Subject: Re: [RFC][PATCH 2/2] Virtualization of IPC
Date: Fri, 24 Mar 2006 11:13:20 -0800 [thread overview]
Message-ID: <1143227600.19152.81.camel@localhost.localdomain> (raw)
In-Reply-To: <44242DFE.3090601@sw.ru>
On Fri, 2006-03-24 at 20:35 +0300, Kirill Korotaev wrote:
> This patch introduces IPC namespaces, which allow to create isolated IPC
> users or containers.
> Introduces CONFIG_IPC_NS and ipc_namespace structure.
> It also uses current->ipc_ns as a pointer to current namespace, which
> reduces places where additional argument to functions should be added.
In three words, I think this has "too many #ifdefs".
The non-containerized or namespaced case should probably just be one,
static namespace variable that gets wrapped up in some nice #ifdefed
hlper functions.
For instance, instead of this:
+#ifdef CONFIG_IPC_NS
+#define msg_ids (*(current->ipc_ns->msg_ids))
+#endif
Have
#ifdef CONFIG_IPC_NS
static inline struct ipc_namespace *current_ipc_ns(void)
{
return current->ipc_ns;
}
#else
static inline struct ipc_namespace *current_ipc_ns(void)
{
return &static_ipc_ns;
}
#endif
And use current_ipc_ns()->msg_ids. I can't imagine that gcc can't
figure that out and turn it back into effectively the same thing.
I really dislike the idea of replacing nice variables with macros that
add indirection. They really might fool people. Putting a function
there is much nicer.
Why avoid to passing these things around as function arguments? Doesn't
that make it more explicit what is going on, and where the indirection
is occurring? Does it also make refcounting and lifetime issues easier
to manage?
BTW, Did you see my version of this?
-- Dave
next prev parent reply other threads:[~2006-03-24 19:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-24 17:23 [RFC] Virtualization patches for IPC/UTS. 2nd step Kirill Korotaev
2006-03-24 17:31 ` [RFC][PATCH 1/2] Virtualization of UTS Kirill Korotaev
2006-03-24 19:09 ` Eric W. Biederman
2006-03-24 19:35 ` Kirill Korotaev
2006-03-24 19:50 ` Eric W. Biederman
2006-03-27 19:40 ` Eric W. Biederman
2006-03-24 20:28 ` James Morris
2006-03-28 3:45 ` Sam Vilain
2006-03-24 17:35 ` [RFC][PATCH 2/2] Virtualization of IPC Kirill Korotaev
2006-03-24 19:13 ` Dave Hansen [this message]
2006-03-24 21:27 ` Herbert Poetzl
2006-03-28 5:26 ` Sam Vilain
2006-03-24 20:09 ` Eric W. Biederman
2006-03-27 15:33 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1143227600.19152.81.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@vilain.net \
--cc=serue@us.ibm.com \
--cc=torvalds@osdl.org \
--cc=xemul@sw.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome