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-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
