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

[Greg KH <greg@kroah.com>]

On Thu, Mar 17, 2011 at 04:08:47PM -0400, Prarit Bhargava wrote:
> >>   
> >>     
> >>> +}
> >>> +
> >>> +/* add additional sysfs files here */
> >>> +static struct device_attribute smbios_attrs[] = {
> >>> +	__ATTR_RO(version),
> >>> +};
> >>>     
> >>>       
> >> So a whole new class just for a single version file in sysfs?
> >>
> >>     
> 
> Right now it is only the version file.  Eventually I was thinking that
> this would grow to include sysfs entries for the BIOS info (date,
> vendor, etc.) and Product and Chassis info, not to mention all the
> various SMBIOS structs.  We have at least one driver that goes through a
> lot of trouble to get this info, and IIRC, the PCI code now outputs
> type41 and type9 fields for the network device naming stuff.
> 
> I thought that meant it needed a new class but, as you pointed out, that
> isn't the case.  I'll ping kernel-mentors and see if anyone there might
> point me to the right class for this data.

See my other response for how to go about this.

> >> I'm confused, what exactly are you trying to show here that you can't
> >> show in the existing device/class structure?
> >>
> >>     
> 
> I want to show the version of the SMBIOS on the system.  But it doesn't
> seem to make sense to me to expose it in the DMI sysfs code.  The SMBIOS
> provides the DMI code, not the other way around.  We've become used to
> the DMI code, and we're adding SMBIOS decoding to it but the other parts
> of the kernel are doing their own decoding of the SMBIOS to get
> additional info.  To me, at least, this means we should have a central
> place for it.

Ok, that's fine.  But you can't remove the existing DMI files and
symlinks, so how are you anticipating handling all of that?

This seems like a lot of work at the moment just for a version file,
let's see some more use of this which would justify it being added to
the kernel first.

thanks,

greg k-h