[PROPOSAL] enhanced table dumping

[Stefan Reinauer]

* Eric W. Biederman <ebiederman at lnxi.com> [050118 12:51]:
> I agree that there is an issue particularly with respect to
> interrupts.  A lot of this has waited until we have the time to
> do this properly.  

I agree. However I also think we are coming close to the point were
the existing infrastructure is fine enough to handle distributed table 
generation sanely.

> > Autocreation of those tables should belong to the driver code of each
> > supported device. 
> 
> No.  The devices should have no idea about the format of the data
> we present to the user.  We should push all of the information into
> the device tree so we can derive it from there.

This is certainly true. But it will require some extra layer to be
introduced that is completely missing at the moment. Representation of
IOAPICs in the device tree are completely missing at the moment for
example. We will also need quite some extra information from the config
files.

> No.  A write_tables method is bad.  We need to enhance the dynamic
> device tree with irq information.  And possible with something like
> pci class so we can recognize devices with well know software programming
> interfaces.

ACPI has things like IRQ override entries in it's MADT. There are quite
some other pretty exceptional situations of working around hardware
layout and kernel design allowed by the specification. I am not sure how
we want to associate information like this with a certain device. Is it
part of the "mainboard" device then? I am scared that we have to invent 
a proper representation of things like this, just to be able to convert
it to acpi later on while in the end ACPI tables are simple to produce
and on non-x86 the hardware and linux kernel is less broken.

> > This would also allow to extend the generic information provided by the
> > bridges, by adding such functionality to the mainboard specific code, so
> > we won't end up with something that is worse than now in any case.
> 
> I think allowing additional work to be done at a per port level
> is a valid critique.  I would prefer we leave it until we find an
> actual need however.

This might be now, even though I am probably able to work around by
factorizing the ACPI code seperating the table creator functions and the
main function calling those. This one would go to the motherboard
directory, next to mptable.c and irq_table.c.
The problem I have is that I designed the ACPI code originally for the
AMD Solo motherboard, and someone updated it to be useful on the Epia.
But with every new motherboard there need to be different devices filled
into the MADT.
Say "then drop ACPI", but Linux is not able to boot this machine
properly without ACPI. As sad as it is.

> > Roughly thinking, table_t could look like:
> 
> That is terrible.
 
:-)))) Which is why I kept myself from implementing it yet. 

> For a subset of the idea look at how we generate the cpu information and
> the memory information directly from the LinuxBIOS table already.
 
Can you give me a quick pointer? I am not sure that i am looking at the
right piece of code.

> We need an internal format for the information that we can consume and
> control, and enhance.  The fact that we are passing on that information is
> secondary.
 
I agree, though plugging a good concept between 2 broken ones might be
hard.

> For IRQ routing something very like the work done with open firmware
> is needed.  Open firmware actually cannot represent x86 irq routing
> as there is it cannot handle a the separate descriptions of apic and
> non-apic modes.  But otherwise it should be able to handle everything.

How does it handle APIC modes? If there is an APIC, I don't see any need
to go non-APIC except for academical interest.


Stefan