Re: [PATCH 1/1] boot: Put initcall_debug into its own Kconfig option DEBUG_INITCALL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 13, 2012 at 9:18 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux