[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120810152604.GA27585@sergelap>
Date: Fri, 10 Aug 2012 10:26:04 -0500
From: Serge Hallyn <serge.hallyn@...onical.com>
To: Josh Triplett <josh@...htriplett.org>
Cc: Alex Kelly <alex.page.kelly@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Heiko Carstens <heiko.carstens@...ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Kees Cook <keescook@...omium.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 2/3] fs: Make core dump functionality optional
Quoting Josh Triplett (josh@...htriplett.org):
> On Fri, Aug 10, 2012 at 08:23:23AM -0500, Serge Hallyn wrote:
> > Quoting Alex Kelly (alex.page.kelly@...il.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 :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists