From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Darren Hart <dvhart@infradead.org>
Cc: "Len Brown" <len.brown@intel.com>,
"Pali Rohár" <pali.rohar@gmail.com>,
"Corentin Chary" <corentin.chary@gmail.com>,
"Mario Limonciello" <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
Date: Sat, 15 Apr 2017 00:45:30 +0200 [thread overview]
Message-ID: <2216131.lxtCY30Ovb@aspire.rjw.lan> (raw)
In-Reply-To: <20170412230854.GA11963@fury>
On Wednesday, April 12, 2017 04:08:54 PM Darren Hart 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?
>
> 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.
A couple of loose thoughts here.
In principle there could be a "generic default WMI driver" or similar that would
"claim" all WMI "devices" that have not been "claimed" by anyone else and would
simply expose them to user space somehow (e.g. using a chardev interface).
Then, depending on how that thing is implemented, opt-in etc should be possible
too.
Thanks,
Rafael
next prev parent reply other threads:[~2017-04-14 22:51 UTC|newest]
Thread overview: 101+ 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: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 15:40 ` Mario.Limonciello
2017-04-13 16:06 ` Darren Hart
2017-04-13 15:40 ` Mario.Limonciello
2017-04-13 15:40 ` Mario.Limonciello
2017-04-18 7:36 ` Andy Shevchenko
2017-04-18 14:08 ` Mario.Limonciello
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:55 ` Mario.Limonciello
2017-04-13 15:57 ` Andy Lutomirski
2017-04-13 16:54 ` Mario.Limonciello
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:39 ` Mario.Limonciello
2017-04-13 17:44 ` Andy Lutomirski
2017-04-13 17:49 ` Mario.Limonciello
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
2017-04-13 17:45 ` Mario.Limonciello
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 20:38 ` Mario.Limonciello
2017-04-13 23:51 ` Darren Hart
2017-04-14 17:42 ` Mario.Limonciello
2017-04-14 17:42 ` Mario.Limonciello
2017-04-14 18:27 ` Darren Hart
2017-04-14 19:04 ` Mario.Limonciello
2017-04-14 19:04 ` Mario.Limonciello
2017-04-14 22:45 ` Rafael J. Wysocki [this message]
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:29 ` Mario.Limonciello
2017-04-19 16:54 ` Pali Rohár
2017-04-19 17:24 ` Mario.Limonciello
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 21:55 ` Mario.Limonciello
2017-05-05 23:44 ` Darren Hart
2017-05-06 0:51 ` Mario.Limonciello
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:36 ` Mario.Limonciello
2017-05-08 15:47 ` Darren Hart
2017-05-08 16:00 ` Mario.Limonciello
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 18:26 ` Mario.Limonciello
2017-05-08 19:09 ` Darren Hart
2017-05-08 19:11 ` Mario.Limonciello
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 19:21 ` Mario.Limonciello
2017-05-08 20:59 ` Pali Rohár
2017-05-08 21:18 ` Mario.Limonciello
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 1:10 ` Mario.Limonciello
2017-05-09 7:29 ` Pali Rohár
2017-05-09 18:10 ` Mario.Limonciello
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: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=2216131.lxtCY30Ovb@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=Mario_Limonciello@dell.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corentin.chary@gmail.com \
--cc=dvhart@infradead.org \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.