Date:	Mon, 21 Mar 2011 11:45:58 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Greg KH <greg@...ah.com>
CC:	linux-kernel@...r.kernel.org, dzickus@...hat.com
Subject: Re: [PATCH]: SMBIOS: Add initial code and export version via sysfs

gregkh wrote:
>Sounds good, how are you going to do this?  In binary way (like efivars
>does it) or in text files like the current DMI code does?

gregkh wrote:
>What exactly are you
>trying to achive?  What do you want to show in sysfs and how do you
>expect it to look?

Greg, sorry for repeating myself in some of the below.  You're right in your
implication that I was not explaining myself very well.  I figured the
best thing to do was to start my argument from the beginning...

The last update to the DMI specification was in 2003.  It has since been
replaced by SMBIOS.  A new SMBIOS specification was released in February
2011.

While looking at the SMBIOS related code in the kernel, I noticed that the
DMI code was actually being overloaded to include SMBIOS structures and
that other sections of code (ia64 setup, x86 setup & pci, Dell platform
driver(s), the new PCI sysfs labe codel, hotplug drivers, the HP watchdog
driver, and the sigmatel sound driver, all used a method to derive values
from the SMBIOS structs.  Please note, that this list is very likely
incomplete.  I only did a search on 'smbios' in the kernel.

As I previously said, it would be nice if we did this in a single location
instead of throughout the kernel, and fix the overloading of the DMI code
currently in the kernel.

For now, my intention is to leave the code as similar to the DMI code as
possible.  That is, export the SMBIOS information via text files in
sysfs (although the layout of the files will obviously change, see below).

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

I will create a new sysfs class, to temporarily exist next to the
current /sys/devices/virtual/dmi entry, which would export values from
SMBIOS.  I want to introduce this slowly and in several stages:

1.  Introduce the new SMBIOS infrastructure in a [relatively] simple patch,
and export the smbios version # to the kernel.

The model I had in mind was:

/sys/devices/virtual/smbios/id/

/sys/devices/virtual/smbios/id/[type#]/...

ie) a straight mapping of the smbios tables.  It should be up to the
individual
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.

2.  Export all of the SMBIOS information in the current (Feb 2011) spec.  If
all goes well I think the correct thing to do is to update
feature-removal-schedule.txt with a well-defined timeline at this point.

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.

4.  Notify external userspace programs of the change.  To be honest, I
haven't
thought much about this other than to take a couple of systems and see what
is using those values and let them know of the impending change.

[This next part is wishful thinking ;)] ... I suppose at some point it
would be
possible to put in a printk into the *existing* DMI sysfs files to indicate
that they were being deprecated.  I can certainly see how that would be
frowned upon; while it would be a loud nasty warning, it also might be one
of those warnings people just learn to ignore.

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

I'm hoping to lean on what you did for the udev change, Greg.  IIRC, you
kept the old code and the new udev code in place for a while and then made
the final change after some time.  I can see that would be the best idea
here...

P.

--
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/

Powered by blists - more mailing lists