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:	Thu, 17 Mar 2011 13:15:34 -0700
From:	Greg KH <greg@...ah.com>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org, dzickus@...hat.com
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
--
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/