Re: [PATCH]: SMBIOS: Add initial code and export version via sysfs

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> In this way we would limit the amount of change to external packages
> (ie, initscripts, network init, etc.) to hopefully only filename changes.

Why change them at all. SMBIOS provides everything DMI BIOS interfaces
did, so we should just continue to provide them to userspace exactly as
before, but possibly sourced from other locations. There simply isn't a
need to break anything user side. Maybe in five or ten years time someone
will delete the old stuff as nobody uses it any more but it's not an item
that needs hurrying.

Also distinguish between DMI and the DMI BIOS interfaces, the two are
rather different beasts.

> drivers & subsystems to link back to the files.  Of course, the SMBIOS code
> would provide lookup functions similar to the ones provided by the existing
> DMI code to aid drivers in their lookups.

I'm wondering why put all the SMBIOS complexity into the kernel, but then
I wonder likewise about some of the DMI stuff still 8)

> 3.  Modify drivers to use the new SMBIOS table lookups, etc, instead of
> DMI table lookups.  This is relatively easy, IMO.  I will try to keep
> dmi* functions identical to the new smbios* lookup functions.  That code
> works
> well, and isn't in need of change.

I'd actually suggest one change. In using dmi_ naming and DMI alone the
original code made the assumption it was a PC specific tool for doing
fixups and the like. If we are going to tweak it then we should probably
recognize that want the kernel needs to provide to drivers isn't (for the
most case) SMBIOS lookup it's generic "Platform name" etc and these could
have been populated from things other than SMBIOS (OpenFirmware,
DeviceTree, whatever).

It doesn't really change the interface but if you are going to be
renaming things maybe a better naming would be worth it ?

> 5.  After a release (or some other set period of time defined in
> feature-removal-schedule.txt), remove the old DMI code.

This is a user API so really it wants to hang around for a long time, and
given SMBIOS can just provide the same names as well trivially it might
as well just stay there until no distro is using it, then get a _LEGACY
config, then vanish. Think multiples of years.

Alan