Matthew Garrett, werkzaam als kernelontwikkelaar bij Red Hat, heeft op zijn weblog de claims van een Ubuntu-gebruiker ontkracht dat Foxconn bewust Linux kapotte acpi-code voorschotelt. Foxconn lijkt geen schuld te hebben.
Eind vorige week schreef een Ubuntu-gebruiker op het forum van zijn Linux-distributie dat zijn moederbord last had van vastlopers en kernelfouten. Na het disassembleren van de bios leek het er sterk op dat dit te maken had met acpi: Linux zou verkeerde data voorgeschoteld krijgen, omdat problemen met het moederbord opgelost leken als de Windows-code geladen werd. Al snel liet Garrett weten dat de gebruiker zijn conclusies op verkeerde informatie baseerde. Dit bevestigde hij nadat hij de relevante acpi-tabellen geanalyseerd had.
In de acpi-data wordt gecontroleerd of het besturingssysteem de zogenoemde '_osi'-methode ondersteunt. Als dat het geval is wordt een bepaald codepad gevolgd, als dat niet het geval is valt de tabel terug op de oudere '_os'-code. Linux ondersteunt dezelfde acpi-features als Windows en laat de acpi-tabellen daarom weten Windows te zijn. Het resultaat daarvan is dat dezelfde variabele wordt ingesteld als in wanneer dat daadwerkelijk een recente Windows-editie gestart zou zijn.
Als er onverhoopt toch wordt teruggevallen op de oudere '_os'-methode, dan wordt er echter een andere variabele ingesteld. Deze situatie kan echter niet voorkomen onder recente Linux-distributies, omdat de Linux-kernel al sinds de release van versie 2.6.9 vier jaar geleden zich voor de acpi-code als Windows voordoet. Er is geen mogelijkheid om vanuit de acpi-tabellen te ontdekken dat Linux wordt gebruikt. Van sabotage kan dan ook geen sprake zijn, stelt Garrett, temeer daar elk codepad in de acpi-tabellen ook door op zijn minst één Windows-versie gevolgd wordt.
Al met al lijkt Foxconn weinig te verwijten: het bios levert geen kapotte code aan Linux en de acpi-specificatie wordt nergens genegeerd. De veranderingen die de Ubuntu-gebruiker in de code heeft doorgevoerd zorgen er alleen maar voor dat waarschuwingen niet meer voor de gebruiker zichtbaar zijn: de onderliggende fouten bestaan nog steeds. Het oplossen van die fouten in de Linux-code is niet zo eenvoudig, omdat er toegang tot de hardware voor nodig is en die heeft Garrett niet. In ieder geval is het geen fout van Foxconn, hoogstens in de manier waarop Linux code geïmplementeerd heeft.