Myron Stowe wrote: > ACPI in new systems does tend to present a lot of challenges. > My job is > new platform enablement focused which more often than not > translates to > "helping discover and fix BIOS/ACPI issues" so I definitely > understand. > > You also astutely point out that ACPI's static tables are > available for > use by an OS - or OSPM in ACPI speak - much earlier than its > namespace. > This is true but it is also our belief that no one uses it except HP. Are you watching what goes on in embedded systems or only the PC / server marketplace? > I see how one's life could be easier relying on the BIOS setting up > static tables such as either the SMBIOS or SPMI. That way the BIOS is > taking the dynamic aspects into account relieving the OS, or > OS/platform > bring up engineer, from such. In such a case, what benefits does the > SPMI table provide as opposed to the SMBIOS table? It gives you twice as many chances to find a sufficiently non-buggy table to get on with your work ;-} > > I would be more comfortable if you kept this code, perhaps > > suppressed under a "CONFIG_IPMI_SPMI" config option. > > I just don't see enough remaining value in keeping the SPMI table > capability. It seems to be redundant, and if truly so, just adds > unnecessary code, complexity, and maintenance aspects to the > driver. We > typically don't keep code in the kernel just for bring up efforts. Well, I'm not doing any such bring-up work so I will step out of the discussion here. But I'll leave you with a bit of a curse: if you remove this code, I predict that the person it will come back to bite is you... >Bela<-- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
