Messages in this thread | | | Date | Thu, 17 Mar 2011 13:15:34 -0700 | From | Greg KH <> | Subject | Re: [PATCH]: SMBIOS: Add initial code and export version via sysfs |
| |
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
| |