All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH] make cr depend on all namespaces
Date: Mon, 15 Mar 2010 16:52:44 -0500	[thread overview]
Message-ID: <20100315215244.GA5791@hallyn.com> (raw)
In-Reply-To: <4B9EAA5D.1080802-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> 
> Serge E. Hallyn wrote:
> > This should let us get rid of some ifdefed code and reduce
> > chances for bad config combinations.  There's really no reason
> > to support it.
> 
> I disagree.
> 
> You are right that this will reduce the changes of bad config
> combinations.
> 
> However, it will also introduce some restrictions on the kernel
> config which are unnecessary. Some people may not want to have
> all namespaces configured.

Why?  The only reason right now to disable namespaces is for
kernel size.

> Note that the namespaces are independent in the sense that we
> don't need to test all combination of all namespaces - instead,
> I consider turning on/off one at a time to be safe enough.

And do you do that?  :)  It still gets more complicated bc
you have things like sysvipc and posix mq which both can allow
ipc_ns.

> (FWIW, is it because you only wanted to show a point that you
> only remove UTS_NS ifdefs ?)

It was just right there in my face...

Anyway if you don't take this patch then the UTS_NS code I
removed should have 'name' put under ifdef to avoid a build
warning.

-serge

  parent reply	other threads:[~2010-03-15 21:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 20:05 [PATCH] make cr depend on all namespaces Serge E. Hallyn
     [not found] ` <20100315200559.GA25911-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-15 20:22   ` Nathan Lynch
2010-03-15 21:45   ` Oren Laadan
     [not found]     ` <4B9EAA5D.1080802-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-15 21:52       ` Serge E. Hallyn [this message]
     [not found]         ` <20100315215244.GA5791-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2010-03-15 22:09           ` Oren Laadan
     [not found]             ` <4B9EB02C.8000204-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-15 22:23               ` 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=20100315215244.GA5791@hallyn.com \
    --to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.