On Tue, Sep 28, 2004 at 01:23:53AM -0500, Segher Boessenkool wrote: > > It is a > > non-full-featured firmware thing. If you take a look at MIPS, ARM, > > SH, PPC embedded platforms you'll see a similar thing. But wait, > > you'll even see interrupt routing tables in the decidedly not embedded > > Alpha architecture. :) Linux does do it, and there is a very clear > > infrastructure for managing routing tables and standard/non-standard > > PCI swizzle mechanisms. > > Sure. But the interrupt _assignment_ should be done by firmware.
I can't argue with ideaology. > > Again, on some platforms, not this one. Let's just agree that > > not everything is a x86/BIOS or ppc64/pmac/OF machine that > > has this done in some blackbox firmware. > > Oh, I believe that. But the firmware should be fixed, not a > terrible hack added to Linux. > > Segher > > p.s. And I know this isn't always practically possible; but why > then support a product like that at all, in the Open Source > community? By this reasoning, we should also not support the many BIOS/OF platforms that report incorrect data and have to have their reported data fixed up by the kernel. That's gross too by the same measure. To answer your question, we support the products because other than this one minor detail, the platforms generally have merits that far outweigh the "horrors" of having a very concise interrupt routing table in the kernel. The same reasoning is true in the case of BIOS/OF bugs that are worked around. it's not practical to fix that firmware, but we don't throw away those platforms in defiance. Frankly, there wouldn't be much of anything in the kernel (anything with a PCI quirk must go). More importantly, the maintainers of the kernel, from Linus down through each architecture have made this practice acceptable policy for many many years. -Matt
