public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, dzickus@redhat.com
Subject: Re: [PATCH]: SMBIOS: Add initial code and export version via sysfs
Date: Thu, 17 Mar 2011 15:55:04 -0400	[thread overview]
Message-ID: <4D826718.3030001@redhat.com> (raw)
In-Reply-To: <20110317193023.GA16790@kroah.com>



On 03/17/2011 03:30 PM, Greg KH wrote:
> On Thu, Mar 17, 2011 at 09:57:54AM -0400, Prarit Bhargava wrote:
>   
>> The existing DMI code, drivers/firmware/dmi.c, is not really parsing DMI.  It
>> is actually SMBIOS code that is using the old DMI infrastructure to expose
>> SMBIOS entries.
>>
>> We should be doing the following:
>>
>> 1.  Looking for SMBIOS (either EFI or mapped to it's standard location,
>>     0xF0000)
>> 2.  If found, look for the SMBIOS' Intermediate Structure (aka "DMI" entry)
>> 3.  If not found, look for an "old" DMI structure.
>>
>> DMI is a predecessor of SMBIOS, so we should start treating it as such.
>>     
> Why?  What is this change going to buy us in the end?  Heck, right now,
> what's the benefit?
>   

It's wrong.  DMI doesn't give us SMBIOS information -- it's the other
way around.  There's also a bunch of other stuff from SMBIOS being used
in the kernel (see pci slots and hotplug drivers).

It would be nice to have a single place for this, no?

>   
>> For this patch I have introduced drivers/firmware/smbios.c, exported the
>> SMBIOS version through sysfs, and modified the DMI code such that
>>
>> a) dmi_scan_machine() is now called from init_smbios(), and
>> b) if an SMBIOS is found, the values in the SMBIOS STEP structure are used
>> in dmi_scan_machine().
>>
>> Right now, removing the DMI code is not an option.  It is used by common
>> initscripts, etc., to bringup the system.  Later modifications in this area will
>> include additional parsing of the SMBIOS structs and a simultaneous cleanup
>> of the DMI code.
>>     
> Care to show follow-on patches that convert things to a manner which you
> think it should look like?
>
>   

I haven't written anything yet :) -- I was planning on exporting the
SMBIOS structs (all types) though.

>> --- /dev/null
>> +++ b/drivers/firmware/smbios.c
>> @@ -0,0 +1,175 @@
>> +#include <linux/dmi.h>
>> +#include <linux/efi.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/smbios.h>
>> +
>> +#include <asm/setup.h>
>> +
>> +int smbios_present = 0;
>> +struct smbios_step *smbios_step;
>> +static struct device *smbios_dev;
>>     
> A "raw" struct device?  Why?  You should never do this, that's not the
> way to use a 'struct device'.
>
>   

Ah, okay -- my familiarity with sysfs is very minimal.  I'll ask on
kernel-mentors for a pointer to "good" code.

> Let's back up here, what exactly are you trying to show in sysfs?  Where
> are your Documentation/ABI/ entries that show these new files, what they
> contain, and how to use them?
>   

Obviously missing -- I will add this on my next patch.

>   
>> +/* The actual address of the SMBIOS */
>> +static unsigned long smbios_addr = 0;
>> +
>> +#ifdef CONFIG_SYSFS
>>     
> You should never need this in your .c file.
>
>   

Will remove.

>> +static ssize_t version_show(struct device *dev,
>> +			    struct device_attribute *attr, char *buf)
>> +{
>> +	return snprintf(buf, PAGE_SIZE, "%u.%u\n", smbios_step->major,
>> +		       smbios_step->minor);
>>     
> As you "know" you are only returning a simple value, why the snprintf()?
> Hint, don't, it's overkill and how do you "know" that the buffer is
> PAGE_SIZE big?  Hint, you don't, so stick to a small buffer like you
> are, and all is fine.
>   

:)  Will do.  Thanks :)

>   
>> +}
>> +
>> +/* 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?
>
> I'm confused, what exactly are you trying to show here that you can't
> show in the existing device/class structure?
>
>   
>> +
>> +static struct class smbios_class = {
>> +	.name = "smbios",
>> +	.dev_release = (void(*)(struct device *)) kfree,
>>     
> As stated before, nice try, but no. :)
>
>   

Right -- I'll go off and try to figure out the proper way to do this. 
Sorry ... I was following along with what the existing DMI code does.

>   
>> +};
>> +
>> +static struct device *smbios_dev;
>> +
>> +static int __init smbios_setup_sysfs(void)
>> +{
>> +	int attr, i, ret = 0;
>> +
>> +	ret = class_register(&smbios_class);
>> +	if (ret)
>> +		goto out;
>> +
>> +	smbios_dev = kzalloc(sizeof(*smbios_dev), GFP_KERNEL);
>> +	if (!smbios_dev) {
>> +		ret = -ENOMEM;
>> +		goto out_cleanup_class;
>> +	}
>> +
>> +	smbios_dev->class = &smbios_class;
>> +	dev_set_name(smbios_dev, "id");
>> +
>> +	ret = device_register(smbios_dev);
>> +	if (ret)
>> +		goto out_cleanup_smbios_dev;
>> +
>> +	for (attr = 0; attr < ARRAY_SIZE(smbios_attrs); attr++) {
>> +		ret = device_create_file(smbios_dev, &smbios_attrs[attr]);
>>     
> You just raced userspace when you created this file, causing it massive
> problems if it was expecting when the hotplug event happened that this
> file would be present.  Please don't do that, we have the infrastructure
> to do this properly, please use it.
>
>   

np -- thanks for the info Greg.

P.

> thanks,
>
> greg k-h
>   

  reply	other threads:[~2011-03-17 19:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-17 13:57 [PATCH]: SMBIOS: Add initial code and export version via sysfs Prarit Bhargava
2011-03-17 19:09 ` Alan Cox
2011-03-17 19:12   ` Prarit Bhargava
2011-03-17 19:22     ` Greg KH
2011-03-17 19:30 ` Greg KH
2011-03-17 19:55   ` Prarit Bhargava [this message]
2011-03-17 20:07     ` Greg KH
2011-03-21 15:45       ` Prarit Bhargava
2011-03-21 16:06         ` Alan Cox
2011-03-27 22:29           ` Prarit Bhargava
2011-03-17 20:08     ` Prarit Bhargava
2011-03-17 20:15       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D826718.3030001@redhat.com \
    --to=prarit@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox