mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: david@lang.hm
To: Andi Kleen <andi@firstfloor.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: why are namespaces required?
Date: Fri, 8 Aug 2008 08:08:08 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.1.10.0808080803060.32620@asgard.lang.hm> (raw)
In-Reply-To: <87ej4z4uf1.fsf@basil.nowhere.org>

On Fri, 8 Aug 2008, Andi Kleen wrote:

> Alexey Dobriyan <adobriyan@gmail.com> writes:
>>
>> And while we're at it, data from my usual config adding _NS options
>> one-by-one.
>>
>> 	$ size vmlinux-000 vmlinux-uts-ns vmlinux-ipc-ns vmlinux-user-ns vmlinux-pid-ns
>> 	   text    data     bss     dec     hex filename
>> 	2560804  217296  225280 3003380  2dd3f4 vmlinux-000
>> 	2560948  217296  225280 3003524  2dd484 vmlinux-uts-ns	(+144)
>> 	2561452  217296  225280 3004028  2dd67c vmlinux-ipc-ns	(+504)
>> 	2561805  217296  225280 3004381  2dd7dd vmlinux-user-ns	(+353)
>> 	2562819  217300  225280 3005399  2ddbd7 vmlinux-pid-ns	(+1018)
>>
>> What amazing .text savings we have here.
>
> Fully agreed. Probably a lot of these CONFIG options should be just dropped.
> They are quite user unfriendly with very little gain.
>
> It seems like there is unbounded growth in different name space options
> which also implies unbounded CONFIG growth. At least they should be all
> consolidated into a single CONFIG.

from a size point of view the namespace options may not have much impact, 
but what about performance? supporting namespaces requires additional 
checking each time something is accessed (not to mention new codepaths).

how about consolodating all the namespace items under a single namespace 
menu item so that they can all be disabled with one click, but people who 
want fine-grained control over the different portions can still have it.

but (going back to my initial post) namespaces should not be forced on for 
!embeded (or if they are then the options to disable namespaces should be 
moved inside the embeded menu)

David Lang

      reply	other threads:[~2008-08-08 15:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  0:54 david
2008-08-08  1:11 ` david
2008-08-08  1:33 ` Alexey Dobriyan
2008-08-08 11:29   ` Andi Kleen
2008-08-08 15:08     ` david [this message]

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=alpine.DEB.1.10.0808080803060.32620@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=adobriyan@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®