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

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

On Tue, Jun 23, 2009 at 06:20:11PM -0400, Len Brown wrote:
> On Tue, 23 Jun 2009, Matthew Garrett wrote:
> 
> > 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.
> 
> Correct.
> 
> Per my previous message...
> 
> Should a platform require them, any and all of the ACPI
> defined/reserved tables can be accessed on an SFI system
> if needed.  Today, the PCI MCFG is the only ACPI table implemented
> in the known universe of SFI systems.

Right. But you've already got a potential conflict when it comes to 
wrapping the MADT - if someone wants a greater set of APIC information 
than you can provide via the SFI APIC table they're going to hit 
interesting problems.

> WRT to native SFI table names...
> 
> int sfi_table_parse(char *signature, char *oem_id, char *oem_table_id,
>                         uint flag, sfi_table_handler handler);
> 
> While the invocations in the tree today have NULL oem_id
> and NULL oem_table_id, it is possible for a vendor to
> stick their own name in there with their own table_id
> and get the OS or a driver to find their home-brewed table
> without reserving a table signature to the SFI spec.

Ok, that looks plausible. Can this be added to the spec as a best 
practice?

> However, should overwhemling demand for table signatures materialize,
> I'm sure that a process can be put in place to manage collisions...

Given the potential for vendors to ship customised Linux kernels, I 
think it'd be beneficial to have that in place before any hardware's 
shipped. The moment we have a collision we have a support nightmare.

> > 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.
> 
> The SFI table signatures are totally independent of the ACPI table
> signatures -- they can not collide.  The only overlap is the XSDT
> itself, which exists in SFI explicitly to separate the ACPI namespace
> from the SFI namespace.

My concern is collisions within the SFI namespace, not collisions 
between ACPI and SFI.

> > 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.
> 
> SFI was invented with the goal to help a somewhat generic 
> distro-supported kernel to boot and run optimally
> on the Moorestown platform.  If SFI helps enable Moorestown
> to participate in even just a small part of the vibrant
> x86 open source development community, than it has been successful.
> 
> Yes, SFI is written to be "generic enough" so that it can be
> used by more than Moorestown.  It is not trying to displace ACPI
> on systems that are willing and able to support ACPI, but it
> is freely available for those platforms that can't.

If SFI's intended to support non-Moorestown platforms then I think we 
need to spend some more time determining what a non-Moorestown SFI 
implementation would look like, what changes would be required in the 
kernel to support that and how to ensure that vendors do this in a 
manner that doesn't make it likely that we'll have incompatible 
impleentations. If it's not then I think the Kconfig and documentation 
need to make that clearer.

-- 
Matthew Garrett | mjg59@srcf.ucam.org