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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D826A4F.9070608@redhat.com>
Date:	Thu, 17 Mar 2011 16:08:47 -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

Sorry Greg, I missed replying to one of your questions.

>>   
>>     
>>> +}
>>> +
>>> +/* 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.

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

Thanks again,

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/