[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    > 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 |

     \ /
      Last update: 2009-06-24 00:59    [W:0.024 / U:4.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site