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@xxxxxxxx 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@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
