Messages in this thread | | | Date | Mon, 21 Mar 2011 16:06:08 +0000 | From | Alan Cox <> | Subject | Re: [PATCH]: SMBIOS: Add initial code and export version via sysfs |
| |
> 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
| |