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
