From: "Pali Rohár" <pali.rohar@gmail.com>
To: Darren Hart <dvhart@infradead.org>
Cc: Mario.Limonciello@dell.com, luto@kernel.org, kernel@kempniu.pl,
rjw@rjwysocki.net, len.brown@intel.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: Tue, 18 Apr 2017 21:28:31 +0200 [thread overview]
Message-ID: <201704182128.31940@pali> (raw)
In-Reply-To: <20170418165631.GD25405@fury>
[-- Attachment #1: Type: Text/Plain, Size: 7447 bytes --]
On Tuesday 18 April 2017 18:56:31 Darren Hart wrote:
> On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote:
> > On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote:
> > > > > No more than exists today with the dcdbas SMI interface
> > > > > (which only if you manually run userspace tools that
> > > > > manipulate the same data you can do that technically).
> > > > >
> > > > > We're all reasonable folks, if there is an instance of this
> > > > > that comes up we can make changes to userspace to fix it.
> > > >
> > > > Right. As Pali pointed out previously, if there is an existing
> > > > class driver / subsystem which supports this functionality we
> > > > should use that.
> > > >
> > > > I suppose one risk will be one GUID exposing both types of
> > > > methods. Those which are used by kernel drivers, and those
> > > > which have no kernel support. Or worse, methods which have
> > > > multiple behaviors depending on their input arguments.
> > > >
> > > > --
> > >
> > > Well the "most" interesting to me is the SMBIOS calling interface
> > > on the regular Dell GUID (WMBA IIRC). That's what is used to
> > > manipulate keyboard LED timeouts in dell-laptop (although
> > > through direct SMI today).
> > >
> > > It's also what is used for other SMBIOS calls like changing
> > > random BIOS settings that shouldn't be generically exposed in
> > > sysfs but should be controlled by manageability tools.
> > >
> > > Example: turning on/off legacy option ROM or changing legacy boot
> > > order.
> >
> > Which basically means that new WMI /dev/ files does not help for
> > Dell.
> >
> > Kernel needs to manipulate with SMBIOS for implementing rfkill,
> > keyboard backlight, display brightness and also needs to receive
> > WMI events for hotkeys. So kernel modules would lock WMI interface
> > for receiving events & sending SMBIOS calls, and userspace would
> > be blocked from usage of this WMI GUID.
>
> This is why we can't rely on a method ID granular filter for which
> methods are exported to userspace. In my previous reply to Rafael, I
> suggested platform drivers decide which method IDs are exported, and
> for platforms with insufficient WMI method ID granularity, we will
> end up exposing methods we also use in the kernel. The WMI
> evaluation will need to be centralized and placed under mutual
> exclusion. The optional wmi evaluation filter would allow for
> drivers to audit incoming calls from userspace to ensure no
> conflict.
>
> It's not ideal - but I believe it addresses our reality.
Ok.
> > I do not think that we can solve this problem easily in
> > vendor-neutral interface. There was argument that WMI API was
> > designed to allow userspace applications call firmware functions
> > directly... But we are using WMI in kernel and we should not allow
> > both kernel and userspace to fight on some WMI API.
>
> We could drop all the in kernel wmi drivers and rely on userspace
> daemons per platform.... but I think we all agree that is not where
> we want this to go. So we'll need to find a compromise. Even then,
> we'd need to avoid competition for common method IDs across multiple
> userspace applications.
I think this is step backward. Current wmi drivers in kernel which
implements class devices should stay in kernel -- independently of fact
if they are provided by WMI API, ACPI API or direct HW access.
> > So for Dell we need for sure some Dell specific interface which
> > covers all needed functionality. I'm not sure what everything Dell
> > software needs, so what about specifying current usage of Dell
> > SMBIOS/WMI functions from existing userspace applications and also
> > planned usage in future? Then from this information we can design
> > kernel and userspace API which can fit for Dell usage.
>
> This was my initial response as well. The biggest problem with it is
> it places Linux imposed restrictions on the WMI mechanism, which
> will ultimately stifle innovation and/or leave Linux as a second
> class citizen for systems which rely on WMI for userspace firmware
> management.
Maybe... I agree that having WMI API for userspace application could be
useful, but it should not be at cost of loosing current kernel drivers
or kernel functionality provided by current kernel wmi drivers.
The question is, who is interested in full WMI access from userspace?
And who already requested it in past? I'm just asking if we are not
going to work on something in which nobody is interested...
Yes, we know from Mario that Dell is interested in WMI access from
userspace. But is there other vendor? At least I do not know, so this is
reason why I suggested to rather create API specially for Dell which
will fully fit for both userspace Dell applications and also kernel dell
wmi drivers to minimize conflicts.
I'm sure that specific API/ABI designed for concrete usage (here in
Dell) would be easier and also better in resolving conflicts and
fighting between kernel & userspace as some fully generic API/ABI which
needs to be designed for everything and everybody.
What worry me is that there will be kernel wmi drivers which due to
conflicts in locking/usage would not be able to allow userspace to
access WMI. Or if their implemented filter would not fullfit for vendor
userspace application (for some reasons), and vendor userspace
application starts blocking kernel wmi modules. This would mean that
user would be in position where must decide if he wants: stable kernel
driver for controlling rfkill/led and receive hotkey presses OR
userspace application which can control charging, setting special BIOS
settings/etc/... And if laptop vendors do not want to coordinate work
with kernel upstream, this situation can really happen.
> > About other vendor WMI's functions... I'm not sure, but there is
> > again possibility that rfkill, leds or hotkeys would exists on
> > same WMI GUID as other maintenance functions (which userspace
> > wants), so export would be again blocked by kernel module for
> > rfkill/leds/hotkeys.
> >
> > Therefore I'm not really sure if some /dev/wmi* API would be
> > usefull, and not always blocked by kernel module which implements
> > rfkill support.
>
> I'd like to also point out that the Linux kernel has a minimal and
> targeted set of WMI drivers generally aimed at making laptops work
> as expected through the only mechanism we had access to.
Yes, that is truth for obvious reason.
> To my
> knowledge, we never sat down to discuss how WMI should be
> implemented in the Linux ecosystem. That leaves us in the situation
> we are in today, in which Linux essentially took the most expedient
> route to making laptops work - which happened to be WMI, but we
> didn't consider the broader implications of that mechanism or how
> what we implemented would interact with full set of functionality
> provided by WMI.
I did not know about any discussion too.
> So our challenge now is to look at WMI as a whole. How should it be
> implemented to achieve feature parity. And then consider how the
> existing drivers fit into that. Please see my proposal in response
> to Rafael's latest reply. I believe it outlines a reasonable
> compromise.
Ok, I will write there other notes.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2017-04-18 19:28 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 [this message]
2017-04-13 17:02 ` Darren Hart
2017-04-13 17:32 ` Andy Lutomirski
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 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=201704182128.31940@pali \
--to=pali.rohar@gmail.com \
--cc=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=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).