From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753627AbdFMRna (ORCPT ); Tue, 13 Jun 2017 13:43:30 -0400 Received: from mail-wr0-f177.google.com ([209.85.128.177]:33245 "EHLO mail-wr0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751826AbdFMRn2 (ORCPT ); Tue, 13 Jun 2017 13:43:28 -0400 From: Pali =?utf-8?q?Roh=C3=A1r?= To: Greg KH Subject: Re: WMI and Kernel:User interface Date: Tue, 13 Jun 2017 19:43:22 +0200 User-Agent: KMail/1.13.7 (Linux/3.13.0-117-generic; KDE/4.14.2; x86_64; ; ) Cc: Mario.Limonciello@dell.com, luto@kernel.org, dvhart@infradead.org, hch@infradead.org, torvalds@linux-foundation.org, andriy.shevchenko@linux.intel.com, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org References: <20170509231639.GB11404@fury> <6e3ce02ce8b74710a3335b4cfa13b9af@ausx13mpc120.AMER.DELL.COM> <20170613165714.GB32546@kroah.com> In-Reply-To: <20170613165714.GB32546@kroah.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3249207.AsGMJjLD9X"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201706131943.22554@pali> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nextPart3249207.AsGMJjLD9X Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Greg! I will try to explain that problem with calling WMI functions. On Tuesday 13 June 2017 18:57:14 Greg KH wrote: > > Getting there requires work in a few areas: > > 1) The OEM/IBV exports the methods and the MOF (in binary form) > > that describes the objects that can be interacted with and what > > kind of data needs to be sent. >=20 > What do you mean by this? In ACPI is stored buffer with binary MOF data. Those data contains=20 description WMI object system where are classes with methods and=20 attributes (similar to C++). Then there are stored mapping from=20 particular class method/attribute to WMI id. If you want to call WMI method (which is basically ACPI method), you=20 need to know WMI id and call specific ACPI method with that id and other=20 magic. Taking those magic values is not easy and WMI kernel drivers just=20 reverse engineered them from ACPI bytecode or other method. But correct way is to parse that binary MOF data and build mapping from=20 classes, methods and attributes to WMI ids (needed for raw ACPI call). Problem is that format of those binary MOF data is unknown (generated by=20 program mofcomp.exe available in all MS Windows systems), but finally I=20 was able to guess its structure and write "decompiler". Search for email with subject "Binary MOF buffer in WMI is finally=20 decoded!" for more details which I sent week ago to LKML. > > 2) Kernel needs to provide a way to userspace to get to this data >=20 > Why, what can userspace do with this? Userspace want to call WMI method "Method1" from WMI class "Class1" from=20 namespace "Namespace1". And wants to know signature of that Method1,=20 what are input arguments, what are outputs... Those MOF data contains descriptions of arguments and also information=20 which ACPI method with which WMI id needs to be called to execute above=20 "Method1". =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart3249207.AsGMJjLD9X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAllAJDoACgkQi/DJPQPkQ1LPfQCfZcWWVCNpaRlWF7wGyJArJ7mF d0gAnRmLUqIQ2Tr54PlIKTIfzy1MuXuN =qIR6 -----END PGP SIGNATURE----- --nextPart3249207.AsGMJjLD9X--