[lkml]   [2011]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    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:



    ie) a straight mapping of the smbios tables. It should be up to the
    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
    well, and isn't in need of change.

    4. Notify external userspace programs of the change. To be honest, I
    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


     \ /
      Last update: 2011-03-21 16:49    [W:0.040 / U:67.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site