Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata

[John Bradford]

> > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/