* Domsch, Matt <Matt_Domsch@xxxxxxxx>: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
