tests/acpi-test: do not run iasl on big endian machines
PATCH v2 1/1 tests/acpi-test: do not run iasl on big endian machines
There is an issue with iasl on big endian machines: It cannot disassemble acpi tables taken from little endian machines, so we cannot check the expected tables.
Do not run iasl on those machines until this problem is solved by the acpica community.
---
V1 -> V2:
Addressed an offline tip for a much cleaner macro line, thanks!
tests/acpi-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tests/acpi-test.c +1 -1
@@ -145,7 +145,7 @@ static uint8_t boot_sector[0x7e000] = {static const char *disk ="tests/acpi-test-disk.raw" ;static const char *data_dir ="tests/acpi-test-data" ; -#ifdef CONFIG_IASL +#if G_BYTE_ORDER ==G_LITTLE_ENDIAN && defined(CONFIG_IASL )static const char *iasl =stringify (CONFIG_IASL );#else static const char *iasl;
Signature · 1 line
1.8.3.1
Quoted 8 lines · Marcel Apfelbaum
There is an issue with iasl on big endian machines: It cannot disassemble acpi tables taken from little endian machines, so we cannot check the expected tables.
Do not run iasl on those machines until this problem is solved by the acpica community.
Signed-off-by Marcel Apfelbaum <[email protected]>
Seems too aggressive: can't we detect the broken iasl? E.g. won't it fail to disassemble expected AML files? Also, won't this broken iasl generate corrupt AML on output? If yes we should detect this at configure time instead?
Quoted 23 lines
---
V1 -> V2:
Addressed an offline tip for a much cleaner macro line, thanks!tests/acpi-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tests/acpi-test.c +1
-1@@ -145,7 +145,7 @@ static uint8_t boot_sector[0x7e000] = {static const char *disk ="tests/acpi-test-disk.raw" ;static const char *data_dir ="tests/acpi-test-data" ; -#ifdef CONFIG_IASL +#if G_BYTE_ORDER ==G_LITTLE_ENDIAN && defined(CONFIG_IASL )static const char *iasl =stringify (CONFIG_IASL );#else static const char *iasl;Signature · 1 line
1.8.3.1
Il 20/03/2014 21:16, Michael S. Tsirkin ha scritto:
Quoted 2 lines
Seems too aggressive: can't we detect the broken iasl? E.g. won't it fail to disassemble expected AML files?
Yes.
Quoted 3 lines
Also, won't this broken iasl generate corrupt AML on output? If yes we should detect this at configure time instead?
No, the output is fine. There are patches from Debian (that I updated and applied to Fedora last year) that take care of fixing endianness on output, but no such patches for the disassembly.
On one hand, I'm fine with not running IASL at all on big-endian machines. On the other hand, it will certainly cause the patches to bitrot.
Paolo