Messages in this thread | | | Date | Mon, 15 Sep 2003 20:34:18 +0100 | From | John Bradford <> | Subject | Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata |
| |
> > > I still like the idea of a single config variable to remove all special > > > case code for non-configured CPUs, call it NO_BLOAT or MINIMALIST_KERNEL > > > or EMBEDDED_HELPER as you will. The embedded folks would then have a good > > > handle to do the work and identify sections to be so identified. > > > > Removing the code for non-configured CPUs should be the default. It's > > common sense - if you configure a kernel to support Athlons only, why > > have PIV workarounds in there, unless you're actually debugging a > > kernel problem? > > If we adopt a bit-per-CPUtype or similar approach maybe. But then you have > to go back and test each code section to see if it applies to multiple > types. I'm happy to have existing code stay, as long as there's a way to > clean it up (or attempt to do so). I don't think making super clean is > compatible with stability, and I'd rather see sections marked as > architecture specific as the performance and embedded folks look for > places to clean up the kernel.
Yes, you're right, from a stability point of view I was being a bit impractical. Any idea how many developers are actually regularly testing code on 386s these days, by the way?
> I'm not on a crusade to get the tiny kernel, just to (a) provide a path > for future work started by the config "feature removal" menu, and (b) > avoid inserting a chunk of very specific code without ifdefs, now that > developers have started thinking about putting the kernel on a diet. I > don't suggest we do anything which will break existing code, just not > introduce new bloat right now.
Yeah, breaking existing code can wait until 2.7 :-). Putting the hooks in for future code removal is all we need to do - until somebody actually feels the need to trim something, it might as well stay.
John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |