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

[Josh Triplett]

On Tue, Aug 14, 2012 at 08:03:41AM -0400, Josh Boyer wrote:
> 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.

Fair enough.

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

Most of the other options added via this project have used EXPERT or
EMBEDDED.  This one originally seemed enough like a debugging option to
warrant just using DEBUG_KERNEL and let it default to N, but it sounds
like this one needs to use EMBEDDED as well.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/