Re: [PATCH] Export smbios strings associated with onboard devices

[Alex Chiang <achiang@hp.com>]

* Domsch, Matt <Matt_Domsch@Dell.com>:
> On Thu, Feb 25, 2010 at 03:40:20PM -0600, Alex Chiang wrote:
> > 
> > I agree with this concept, but I don't like the interface.
> > 
> > The name "smbiosname" isn't the proper level of abstraction. We
> > don't want users to care what firmware standard is providing the
> > name (think smbios vs acpi vs open firmware...).
> > 
> > We learned this lesson with exposing ACPI interfaces. Let's not
> > make the same mistake here.
> > 
> > Something like "firmwarename", "fwname", "platformname" etc. is
> > generic, and then the interface will make sense for platforms
> > that do not implement SMBIOS.
> > 
> > I don't particularly care which name you choose as long as it's
> > properly generic.
> 
> I'm not sure I like the generic name.  Then the policy of which
> provider (if there could be >1, which there will be once this can be
> done via ACPI instead of static SMBIOS) gets to use that file name
> becomes kernel-dependent, instead of userspace-dependent.
 
I would imagine that an ACPI _DSM would take precedence over
SMBIOS in that example.

The kernel implements policy like that today already, especially
in the hotplug drivers.

If you modprobe pci_slot, it creates files named with ACPI _SUN.
If you then load pciehp, the names from PCI config space take
precedence.

> What is wrong with having both "smbiosname" and "acpiname" (for lack
> of better names), either, both, or none, as files in the sysfs tree,
> and let userspace set the policy of which one to use if there are >1 ?

sysfs is already confusing enough as it is.

If we present multiple names, every piece of software has to
choose which one to use. Not everyone will simply look at what 
udev creates.

And those will be a maintenance burden forever.

If we have a generic name, then all the non-x86 platforms that do
not have SMBIOS nor ACPI can benefit. In the x86/ia64 world, we
also protect ourselves from new, future firmware standards.

ACPI has been trying to dig itself out of this hole for a long
time, and they're probably stuck with legacy interfaces forever.
I'm hoping not to make the same mistake again.

Thanks,
/ac