Messages in this thread | | | Date | Tue, 23 Jun 2009 23:56:51 +0100 | From | Matthew Garrett <> | Subject | Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support |
| |
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
| |