linux-kernel - Re: [PATCH 1/1] boot: Put initcall_debug into its own Kconfig option DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Aug 2012 18:18:26 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Thai Bui <blquythai@...il.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] boot: Put initcall_debug into its own Kconfig option
 DEBUG_INITCALL

On Mon, Aug 13, 2012 at 03:39:54PM -0700, Randy Dunlap wrote:
> On 08/13/2012 03:08 PM, Thai Bui wrote:
> >Hi all,
> >
> >I am as part of a capstone group at Portland State University is working
> >to tinify the kernel as small as possible. The ultimate goal is to make
> >the kernel small enough to use on micro-controller (or under < 200k).
> >This patch is one of them, it saves 176 bytes on a minimal configuration
> >of the kernel (the bzImage file was reduced from 363264 bytes to 363264
> >bytes applying this patch).
> >
> >Aside from the purpose of reducing the size of the kernel. We are also
> >trying to clean up the kernel by making Kconfig options to compile out
> >the stuffs that aren't used often.
> 
> IMO the kernel already has too many kconfig options.
> 
> Also, personally I would not merge a patch that saves so little memory,
> especially on what I consider a very useful option.

I think Thai undersold his patch significantly; the *compressed* size
went down by 176 bytes, and the uncompressed size went down more than
that.  And that's the savings starting from a very minimal kernel, not
starting from a defconfig kernel.

In any case, do you object to the introduction of a Kconfig option at
all, or to that option defaulting to off?  In particular, would you
object if the option only showed up if EMBEDDED, and defaulted to y?  At
that point, you could reasonably expect that most users and distros will
have it enabled, so you'll be able to count on asking people to enable
it and send you the output.  Would that suffice?

The patch itself seems incredibly straightforward and non-invasive to
me; it just stubs out the global variable and lets GCC fold away all the
code.

At this point, the kernel is running out of major things to cut out to
save space; getting from ~200k (the current smallest kernel possible) to
much less than that will require a pile of patches that save anywhere
from a few hundred bytes to a few kilobytes.  I certainly agree that
those patches need to avoid introducing too much complexity.  However, I
don't think it makes sense to object to a patch that saves space solely
on the grounds that it doesn't save *more* space.  That would make it
impossible to cut out small things, and small things add up.

- Josh Triplett
--
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/