Messages in this thread | | | Date | Tue, 23 Jun 2009 21:45:24 +0100 | From | Matthew Garrett <> | Subject | Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support |
| |
I think I've got a clearer understanding of my objections to this now. The first is that SFI is designed to support the subset of information that's in ACPI and which can't be intuited by the OS. However, that subset is predicated on the system looking like Moorestown. A system that wants to provide any information beyond that subset can't use SFI unless it defines additional tables.
And that brings me onto my second issue. ACPI is sufficiently generalised that there's little need for vendors to add additional tables. SFI isn't, and so vendor adoption is going to require vendor-specific tables. This potentially results in SFI bloating out to cover much of the functionality of ACPI, while at the same time turning into a namespacing nightmare. Without a formal process for adding new tables and without any kind of certification requirements before claiming SFI compatibility, we're looking at a real risk of collisions.
SFI appears to be presented as a generic firmware interface, but in reality it's currently tightly wed to Moorestown and I don't see any way that that can be fixed without reinventing chunks of ACPI. I'm certainly not enthusiastic about seeing this presented as a fait accompli in generic driver code, rather than under arch/x86/moorestown.
-- Matthew Garrett | mjg59@srcf.ucam.org
| |