lkml.org 
[lkml]   [2012]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] boot: Put initcall_debug into its own Kconfig option DEBUG_INITCALL
From
On Mon, Aug 13, 2012 at 9:18 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> 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?

Hiding it behind EMBEDDED might be a start. From a distro perspective,
we actually use this particular option quite often so keeping the
ability to use it as you describe is important.

> 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.

If you're really going to pursue that, I'd suggest hiding the removals
behind a new option that most people won't set.

josh


\
 
 \ /
  Last update: 2012-08-14 14:42    [W:1.370 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site