All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@canonical.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Alex Kelly <alex.page.kelly@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>, Kees Cook <keescook@chromium.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 2/3] fs: Make core dump functionality optional
Date: Fri, 10 Aug 2012 10:26:04 -0500	[thread overview]
Message-ID: <20120810152604.GA27585@sergelap> (raw)
In-Reply-To: <20120810150157.GA23457@leaf>

Quoting Josh Triplett (josh@joshtriplett.org):
> On Fri, Aug 10, 2012 at 08:23:23AM -0500, Serge Hallyn wrote:
> > Quoting Alex Kelly (alex.page.kelly@gmail.com):
> > > Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of core dump.
> > > This saves approximately 2.6k in the compiled kernel, and complements CONFIG_ELF_CORE,
> > > which now depends on it.
> > 
> > Is there another reason than the 2.6k to do this?  My kernels range
> > between 4.8 and 5M, so that's .05% size savings?
> 
> A kitchen-sink kernel might take up that much space, but you can build a
> minimal embedded kernel that only takes up ~200k, at which point 2.6k
> represents a >1% decrease.  Add a few more changes like this, and those
> decreases start to add up.  At this point, no one thing you can chop out
> of the kernel will give you a 100k decrease by itself; you need a pile
> of changes like this one to do that.
> 
> - Josh Triplett

I see.  That's an order of magnitude smaller than what i figured you'd
get with a reasonable kernel  :)

  reply	other threads:[~2012-08-10 15:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10  8:26 [PATCHv4 1/3] fs: Move core dump functionality into its own file Alex Kelly
2012-08-10  8:26 ` [PATCHv4 2/3] fs: Make core dump functionality optional Alex Kelly
2012-08-10 13:23   ` Serge Hallyn
2012-08-10 15:01     ` Josh Triplett
2012-08-10 15:26       ` Serge Hallyn [this message]
2012-08-10 15:33   ` Serge E. Hallyn
2012-08-10  8:26 ` [PATCHv4 3/3] fs: Update coredump-related headers Alex Kelly
2012-08-10 15:37   ` Serge E. Hallyn
2012-08-10 15:33 ` [PATCHv4 1/3] fs: Move core dump functionality into its own file Serge E. Hallyn
2012-08-10 16:17 ` Kees Cook

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=20120810152604.GA27585@sergelap \
    --to=serge.hallyn@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.page.kelly@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=josh@joshtriplett.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.