I missed the "simple, elegant" part. Conceptually elegant maybe.So, basically, if you compile a kernel for a 386, but think that maybeWhy bother with that complexity? Just use 128 byte lines. This allowsMy intention is that we won't have done 128 byte alignments just byThat's a non-issue. 300 bytes matters a lot on some systems. TheIts kind of irrelevant when by saying "Athlon" you've added 128 byte
fact that there are drivers that are bloated is nothing to do with
it.
alignment to all the cache friendly structure padding.
'supporting' Athlons, only if we want to run fast on Athlons. A
distribution kernel that is intended to boot on all CPUs needs
workarounds for Athlon bugs, but it doesn't need 128 byte alignment.
Obviously using such a kernel for anything other than getting a system
up and running to compile a better kernel is a Bad Thing, but the
distributions could supply separate Athlon, PIV, and 386 _optimised_
kernels.
a decent generic kernel. The people who have space requirements would
only compile what they need anyway.
one day you might need to run it on an Athlon for debugging purposes,
you use 128 byte padding, because it's not too bad on the 386? Seems
pretty wasteful to me when the obvious, simple, elegant solution is to
allow independent selection of workaround inclusion and optimisation.
Especially since half of the work has already been done.
If you mean to use the optimise option only to set cache line size, then
that might be a bit saner.
As far as the case study goes though: if you were worried about being
wasteful, why wouldn't you compile just for the 386 and debug from that?
In the model I'm proposing, the 386 kernel would be missing the Athlon
workarounds.