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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Mar 2011 16:06:08 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	dzickus@...hat.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/