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

From: Matthew Garrett
Date: Tue Jun 23 2009 - 16:45:42 EST

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@xxxxxxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at