> You may have noticed the great deal of "hacks" which people have put into
> the kernel over the years to get it to work with the imperfect world of
> hardware. It makes you wonder wether we should waste our time supporting
Well, I added a few trivial firmware workarounds myself, but the question
is how much we can obfuscate the kernel before it gets to the point of
insanity and how much effort one should put in them before deciding it's
not worth the trouble. One-liners are usually fine, but is anything more
complex? And I/O APIC routing table bugs are quite hopeless -- you need
to know the physical layout of traces on a given PCB before even trying to
do anything useful.
> broken hardware... Then again if we didn't we'd only run on 0.1% of the
> boxes out there ;) But... i'm in no way advocating for adding more
> kludges.
SMP hardware is mostly targetted to the server market which seems to care
of Linux due to many customers running it. If they ask vendors for fixes
or choose another brand (surprisingly enough, there are vendors that can
get their MP tables right), the vendors will start fixing bugs. If we
work them around, they will not, as there won't be a reason to.
The "noapic" option should probably get removed -- it was meant as a
debugging aid (as many of the "no*" options) at the early days of I/O APIC
support, I believe... Now the support is pretty stable.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +- 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/