On Fri, 2010-03-05 at 04:58 -0800, Bela Lubkin wrote: > 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? No, I do not watch the embedded system space. Would such folks tend to track openipmi-developer@xxxxxxxxxxxxxxxxxxxxx (at least with respect to IPMI)? If not, are you aware of a specific mail reflector that I should be including in this discussion? > > > 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... I hope I'm not coming off as closed minded and causing you to disengage as most every concern you have raised has been valid and needful of consideration. As mean as putting a jinx on me was (I'm mostly kidding there), you are correct there too: it will be me that it comes back to bite. I still feel that this is worth pursuing as no progress is ever made without some risk but I do want discussions to occur so that I can learn, preferably beforehand, if I am wrong. Myron > > >Bela< -- Myron Stowe HP Open Source Linux Lab (OSLL) -- 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
