Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support

[Matthew Garrett <mjg59@srcf.ucam.org>]

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