Re: RFC: WMI Enhancements

[Andy Lutomirski <luto@kernel.org>]

On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote:
>> > Please pardon my ignorance, but what do we actually gain by exposing WMI to
>> > userspace?  Enabling applications to fetch SMBIOS data?  We already have an
>> > interface for that.  Enabling applications to receive input events?  Likewise.
>>
>> Input notifications are just one aspect that received over WMI.  I don't see any
>> reason to move the notifications out of the kernel.
>>
>> In terms of userspace applications, once a WMI interface to userspace is available
>> libsmbios would change over to that.  Applications using libsmbios would benefit.
>
> Really libsmbios matters here? Hans (added to thread) wrote that
> libsmbios is a relic, something of ages long gone by and a normal user
> should never use it.
>
> If this is truth and libsmbios should not be used, then we probably do
> not need to care about it in changes for WMI.
>
> Hans, Mario, any comment/clarification about it?
>
>> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference
>> > significant enough for anyone to notice?
>>
>> At least for Dell there are optimizations being made when data is requested over
>> the WMI-ACPI wrapper instead of directly via SMI/SMM.
>>
>> For example if the data is a "static" table or the request is to something that is
>> passed thru to the EC it's a big waste of effort to put the CPU in SMM.
>>
>> The savings there is significant.
>
> Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
> of current SMI/SMM direct access?
>

This would make sense to me.  IIRC the only functional difference is
the way that pointers are handled.  It shouldn't be that hard to make
it work for both variants, though.  It could look like:

buf = dell_smbios_alloc(...);
dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
dell_smbios_call(buf);

or similar.