Em Wed, 26 Mar 2014 15:55:07 +0100 "Rafael J. Wysocki" rjw@rjwysocki.net escreveu:
On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
Hi,
Hi,
This is a question for Tony, Boris and Mauro (CCed now).
Currently APEI depends on x86 architecture. It is because of many x86 specific features like "IA-32 Architecture Corrected Machine Check " error source or NMI hardware error notification. However, many other features like "PCI Express Device AER Structure" or GHES via external interrupt can be still used perfectly by other architectures. So my idea is to move x86 dependency away form Kconfig to APEI areas where it really applies to.
I have started refactoring ghes.c driver in that direction. And here comes my confusion, how should we treat x86 related parts, as fixed profile? (which means we could use ACPI_REDUCED_HARDWARE or CONFIG_ACPI_REDUCED_HARDWARE_ONLY define). I would like to ask for your opinion.
That's a good question, and probably depends on how are you mapping the ACPI changes. For example, are you moving acpi out of /arch?
As I answered to a similar questioning, IMHO, the better would be to have the hardware error report mechanisms on /drivers/ras, and have there some Kconfig items that would depend on X86 to enable certain drivers.
Also, I don't like to have something like ACPI_REDUCED_foo. IMHO, the better would be to do the reverse: to have Kconfig symbols enabling the extra X86-specific functionality, and have them mapped into separate files/drivers, with proper KConfig names, like ACPI_X86 or ACPI_X86_NMI.
Yet, it would be better if you could be a little more specific about what are your plans and what are the common/not-common features that you're mapping.
Regards, Mauro