lkml.org 
[lkml]   [2017]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface
Date


> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, October 10, 2017 8:59 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; Andy Shevchenko <andy.shevchenko@gmail.com>;
> LKML <linux-kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org;
> Andy Lutomirski <luto@kernel.org>; quasisec@google.com;
> pali.rohar@gmail.com; rjw@rjwysocki.net; mjg59@google.com; hch@lst.de
> Subject: Re: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce
> userspace interface
>
> On Mon, Oct 09, 2017 at 05:51:52PM -0500, Mario Limonciello wrote:
> > + ret = device_create_file(&wdev->dev, &priv->req_buf_size_attr);
> > + if (ret)
> > + goto fail_create_sysfs;
>
> Why isn't the "WMI core" creating this sysfs file? Why have per-driver
> sysfs files, making all of the different apis totally different? It's a
> "common" attribute that they are all going to have to provide, right?
>
I hadn't really thought about that. I suppose it's entirely reasonable
to have a way that all WMI ioctls for future drivers will advertise the size
of their expected buffer the same way.

So this does beg a question to others on this distribution who have worked
on WMI drivers- do you know of any WM**/ methods with multiple instances
that use different buffer sizes, or is it reasonable to expect that the buffer size
is consistent between instances?

Even in advanced MOF designs I haven't seen it, but this makes me
wonder if an attribute should be created for every instance to be future proof.
(For example $GUID/required_buffer_size/instance0,
$GUID/required_buffer_size/instance1 etc)

> That way you also don't race with userspace :)
>
> thanks,
>
> greg k-h

\
 
 \ /
  Last update: 2017-10-10 16:18    [W:1.255 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site