From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753694AbdFMRQU (ORCPT ); Tue, 13 Jun 2017 13:16:20 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:33559 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249AbdFMRQS (ORCPT ); Tue, 13 Jun 2017 13:16:18 -0400 From: Pali =?utf-8?q?Roh=C3=A1r?= To: Darren Hart Subject: Re: WMI and Kernel:User interface Date: Tue, 13 Jun 2017 19:16:11 +0200 User-Agent: KMail/1.13.7 (Linux/3.13.0-117-generic; KDE/4.14.2; x86_64; ; ) Cc: Christoph Hellwig , "Greg Kroah-Hartman" , Linus Torvalds , Mario Limonciello , Andy Shevchenko , Rafael Wysocki , Andy Lutomirski , LKML , platform-driver-x86@vger.kernel.org References: <20170509231639.GB11404@fury> <20170613070535.GA13252@infradead.org> <20170613153857.GC27850@fury> In-Reply-To: <20170613153857.GC27850@fury> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2822652.m9qIuZ5cZc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201706131916.12144@pali> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nextPart2822652.m9qIuZ5cZc Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > I'll mention this again I suspect in this thread, but rather than a > "WMI filter" we can implement a "WMI proxy". If a kernel driver > needs to own certain WMI calls for LED or Radio management, for > example, all such calls can be proxied through that driver. It can > do the necessary work to update its own state, and still perform the > requested funtion, transparent to the userspace caller. This should > accommodate the addition of new drivers and features to kernel > drivers, without precluding the development of userspace management > or platform daemons. Such WMI proxy implemented in every WMI driver has one design problem: There would be two different kernel APIs to configure some firmware=20 settings. E.g. if particular WMI method implements turning on/off radio=20 devices, then functionality would be exported to userspace via: 1) standard kernel rfkill interface which is device/driver/firmware=20 neutral (and any rfkill application can control it) 2) platform/firmware specific WMI method via newly standard /dev/wmi*=20 interface -- and only vendor specific application could do that and it=20 would work only for this one specific WMI GUID device I do not like idea to have two kernel <--> userspace interfaces to=20 control one thing, plus one interface would be platform dependent. In my opinion any management application which want to control radio=20 switches should use option 1) rfkill interface. And I do not see reason for exporting same duplicate, but platform=20 dependent interface from kernel to userspace. =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart2822652.m9qIuZ5cZc 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) iEYEABECAAYFAllAHdwACgkQi/DJPQPkQ1JesACgkbBjCtkMJPw2b+/+vYTauRRp R8EAn2H2qNlfANznBiiALJAtZqFlftaU =q+5v -----END PGP SIGNATURE----- --nextPart2822652.m9qIuZ5cZc--