From: <Mario.Limonciello@dell.com>
To: <luto@kernel.org>, <dvhart@infradead.org>
Cc: <kernel@kempniu.pl>, <rjw@rjwysocki.net>, <len.brown@intel.com>,
<pali.rohar@gmail.com>, <corentin.chary@gmail.com>,
<andriy.shevchenko@linux.intel.com>,
<linux-kernel@vger.kernel.org>,
<platform-driver-x86@vger.kernel.org>, <linux-pm@vger.kernel.org>
Subject: RE: RFC: WMI Enhancements
Date: Thu, 13 Apr 2017 17:45:08 +0000 [thread overview]
Message-ID: <e44f8516eec543949bc7f740bd18dfa9@ausx13mpc120.AMER.DELL.COM> (raw)
In-Reply-To: <CALCETrUh000Qw4Y2-V9TVfy+6-my3W9xWCUgRin_=Boqf2j8hw@mail.gmail.com>
> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 12:33 PM
> To: Darren Hart <dvhart@infradead.org>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Andrew Lutomirski
> <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Len Brown <len.brown@intel.com>; Pali Rohár
> <pali.rohar@gmail.com>; Corentin Chary <corentin.chary@gmail.com>; Andy
> Shevchenko <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org;
> platform-driver-x86@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
>
> On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Andy Lutomirski [mailto:luto@kernel.org]
> >> > Sent: Thursday, April 13, 2017 10:33 AM
> >> > To: Michał Kępień <kernel@kempniu.pl>
> >> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki
> <rjw@rjwysocki.net>;
> >> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>;
> Corentin
> >> > Chary <corentin.chary@gmail.com>; Limonciello, Mario
> >> > <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy
> >> > Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux-
> >> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux-
> >> > pm@vger.kernel.org
> >> > Subject: Re: RFC: WMI Enhancements
> >> >
> >> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
> wrote:
> >> > >> Hi All,
> >> > >>
> >> > >> There are a few parallel efforts involving the Windows Management
> >> > >> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to
> >> > >> have a round of discussion among those of you that have been involved
> >> > >> in this space before we decide on a direction.
> >> > >>
> >> > >> The WMI support in the kernel today fairly narrowly supports a
> >> > >> handful of systems. Andy L. has a work-in-progress series [2] which
> >> > >> converts wmi into a platform device and a proper bus, providing
> >> > >> devices for dependent drivers to bind to, and a mechanism for sibling
> devices to
> >> > communicate with each other.
> >> > >> I've reviewed the series and feel like the approach is sound, I plan
> >> > >> to carry this series forward and merge it (with Andy L's permission).
> >> > >>
> >> > >> Are there any objections to this?
> >> > >
> >> > > Back in January 2016, I sent Andy a few minor comments about this
> >> > > series. A year later, I offered to iron out the remaining issues and
> >> > > resubmit the series in Andy's name when I find the time. Sadly,
> >> > > things have changed a bit for me since that time and it is unlikely
> >> > > that I will be able to deliver, for which I am sorry.
> >> > >
> >> > > However, browsing Andy's branch I see that most issues have been
> >> > > resolved, though I think some of my remarks [1] have either been
> >> > > missed or silently refuted :)
> >> > >
> >> > > Anyway, I also like this approach and I think this series is a
> >> > > valuable cleanup.
> >> >
> >> > Me too :)
> >> >
> >> > >> In Windows, applications interact with WMI more or less directly. We
> >> > >> don't do this in Linux currently, although it has been discussed in
> >> > >> the past [3]. Some vendors will work around this by performing
> >> > >> SMI/SMM, which is inefficient at best. Exposing WMI methods to
> >> > >> userspace would bring parity to WMI for Linux and Windows.
> >> > >>
> >> > >> There are two principal concerns I'd appreciate your thoughts on:
> >> > >>
> >> > >> a) As an undiscoverable interface (you need to know the method
> >> > >> signatures ahead of time), universally exposing every WMI "device" to
> >> > >> userspace seems like "a bad idea" from a security and stability
> >> > >> perspective. While access would certainly be privileged, it seems
> >> > >> more prudent to make this exposure opt-in. We also handle some of
> >> > >> this with kernel drivers and exposing those "devices" to userspace
> >> > >> would enable userspace and the kernel to fight over control. So - if
> >> > >> we expose WMI devices to userspace, I believe this should be done on
> >> > >> a case by case basis, opting in, and not by default as part of the
> >> > >> WMI driver (although it can provide the mechanism for a sub-driver to use),
> and
> >> > possibly a devmode to do so by default.
> >> >
> >> > I agree. I don't want too see gnome-whatever-widget talking directly to WMI
> and
> >> > confusing the kernel driver for the same thing.
> >>
> >> So there are plenty of other things that can be done by WMI that don't
> >> really make sense to live in the kernel, particularly on what Dell exposes via
> >> WMI.
> >>
> >> If the desire of this group ends up being to not expose WMI by default,
> >> I'd like to at least propose it be exposed for the GUID's Dell is using.
> >>
> >
> > What I'm thinking is an explicit list of GUIDs within the drivers which are to
> > be exposed to user space. The rationale being:
> >
> > * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be
> > exposed to userspace.
> >
> > * Management GUIDs should not change frequently
> >
> > * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an
> > existing driver. This means minimal review time to get upstream, and the
> > ability to include in stable backports as needed. I haven't confirmed
> > this with Greg KH, but I think I can make the case, especially after
> > Andy L's WMI-as-a-bus patches.
>
> Would this be a class driver that would expose a chardev for each
> bound GUID? I agree that this makes a lot more sense than trying to
> shoehorn it into sysfs. Especially since we'd want closing the
> chardev to disable any "expensive" collections that have been enabled
> by ioctl on that chardev. Exposing Dell's smbios entry point through
> this type of device seems reasonable to me.
>
> If we go this route, then I think that exposing the MOF through sysfs
> would make sense -- after all, someone might actually want to parse
> the thing for production purposes.
I agree.
>
> On a sort-of-on-topic note, there's one platform feature that we
> complete fail to handle in the kernel that might be nice to add before
> it gets kludged into lots of userspace code: battery charge controls.
> Thinkpads expose charge thresholds using abominable interfaces, but I
> think they've all been reverse-engineered. Dell probably has them,
> and I bet that Mario would consider telling us how to use them if we
> asked nicely. It might be nice to expose these generically through
> sysfs somewhere.
>
Sure. They're part of the token interface.
https://github.com/dell/libsmbios/blob/master/doc/token_list.csv#L834
next prev parent reply other threads:[~2017-04-13 17:45 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
2017-04-13 7:32 ` Michał Kępień
2017-04-13 13:29 ` Mario.Limonciello
2017-04-13 13:51 ` Pali Rohár
2017-04-13 15:34 ` Andy Lutomirski
2017-04-13 15:40 ` Mario.Limonciello
2017-04-13 16:06 ` Darren Hart
2017-04-13 15:40 ` Mario.Limonciello
2017-04-18 7:36 ` Andy Shevchenko
2017-04-18 14:08 ` Mario.Limonciello
2017-04-13 15:32 ` Andy Lutomirski
2017-04-13 15:39 ` Pali Rohár
2017-04-13 15:44 ` Andy Lutomirski
2017-04-13 16:09 ` Darren Hart
2017-04-13 15:55 ` Mario.Limonciello
2017-04-13 15:57 ` Andy Lutomirski
2017-04-13 16:54 ` Mario.Limonciello
2017-04-13 17:06 ` Darren Hart
2017-04-13 17:39 ` Mario.Limonciello
2017-04-13 17:44 ` Andy Lutomirski
2017-04-13 17:49 ` Mario.Limonciello
2017-04-18 7:54 ` Pali Rohár
2017-04-18 16:56 ` Darren Hart
2017-04-18 19:28 ` Pali Rohár
2017-04-13 17:02 ` Darren Hart
2017-04-13 17:32 ` Andy Lutomirski
2017-04-13 17:45 ` Mario.Limonciello [this message]
2017-04-13 16:08 ` Darren Hart
2017-04-13 7:33 ` Pali Rohár
2017-04-13 16:56 ` Darren Hart
2017-04-13 20:38 ` Mario.Limonciello
2017-04-13 23:51 ` Darren Hart
2017-04-14 17:42 ` Mario.Limonciello
2017-04-14 18:27 ` Darren Hart
2017-04-14 19:04 ` Mario.Limonciello
2017-04-14 22:45 ` Rafael J. Wysocki
2017-04-14 23:05 ` Darren Hart
2017-04-17 22:03 ` Andy Lutomirski
2017-04-17 23:10 ` Darren Hart
2017-04-18 13:07 ` Rafael J. Wysocki
2017-04-18 16:33 ` Darren Hart
2017-04-18 19:28 ` Pali Rohár
2017-04-18 22:49 ` Darren Hart
2017-04-19 7:52 ` Pali Rohár
2017-04-19 16:29 ` Mario.Limonciello
2017-04-19 16:54 ` Pali Rohár
2017-04-19 17:24 ` Mario.Limonciello
2017-04-20 13:14 ` Pali Rohár
2017-04-20 20:44 ` Darren Hart
2017-05-05 21:55 ` Mario.Limonciello
2017-05-05 23:44 ` Darren Hart
2017-05-06 0:51 ` Mario.Limonciello
2017-05-06 1:25 ` Andy Lutomirski
2017-05-08 15:29 ` Darren Hart
2017-05-08 15:36 ` Mario.Limonciello
2017-05-08 15:47 ` Darren Hart
2017-05-08 16:00 ` Mario.Limonciello
2017-05-08 16:04 ` Andy Shevchenko
[not found] ` <CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com>
2017-05-08 18:26 ` Mario.Limonciello
2017-05-08 19:09 ` Darren Hart
2017-05-08 19:11 ` Mario.Limonciello
2017-05-08 17:17 ` Pali Rohár
2017-05-08 19:21 ` Mario.Limonciello
2017-05-08 20:59 ` Pali Rohár
2017-05-08 21:18 ` Mario.Limonciello
2017-05-08 22:17 ` Pali Rohár
2017-05-09 1:10 ` Mario.Limonciello
2017-05-09 7:29 ` Pali Rohár
2017-05-09 18:10 ` Mario.Limonciello
2017-05-09 19:04 ` Andy Shevchenko
2017-05-09 19:16 ` Mario.Limonciello
2017-05-09 19:26 ` Andy Shevchenko
2017-05-09 22:38 ` Pali Rohár
2017-05-09 19:19 ` Pali Rohár
2017-04-20 14:17 ` Christoph Hellwig
2017-04-18 21:14 ` Rafael J. Wysocki
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=e44f8516eec543949bc7f740bd18dfa9@ausx13mpc120.AMER.DELL.COM \
--to=mario.limonciello@dell.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corentin.chary@gmail.com \
--cc=dvhart@infradead.org \
--cc=kernel@kempniu.pl \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pali.rohar@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).