linux-kernel - RE: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <DM6PR19MB263605096186885BF90680E3FA3B0@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Tue, 22 Sep 2020 18:02:54 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Hans de Goede <hdegoede@...hat.com>,
        Divya Bharathi <divya27392@...il.com>,
        "dvhart@...radead.org" <dvhart@...radead.org>
CC:     LKML <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "Bharathi, Divya" <Divya.Bharathi@...l.com>,
        "Ksr, Prasanth" <Prasanth.Ksr@...l.com>,
        Richard Hughes <rhughes@...hat.com>,
        Jared Dominguez <jaredz@...hat.com>
Subject: RE: [PATCH] Introduce support for Systems Management Driver over WMI
 for Dell Systems

> So I've been thinking more about this and to me this whole argument
> sounds a lot like we just want to have our own little corner to
> play in, without needing to worry about what other vendors do.
> 
> And then Lenovo, and HP and who knows else will all want the same
> and we and up with at least 5 different interfaces.
> 
> It is bad enough that we already have to deal with having 5+
> different firmware interfaces for this and worse even for silly
> things like setting the brightness level for the kbd backlight,
> which is such a trivial thing that you would think PC vendors
> should be able to sit down and agree on a single ACPI API for it.
> 
> We are NOT going to take this lets all do our own thing approach and
> also let this trickle up in the stack to the kernel <-> userspace API!
> 
> One of the tasks of the kernel is to act as a HAL and this clearly
> falls under that. Imagine if userspace code would need to use different
> kernel APIs for storage/filesystem accesses depending on if they were
> running on a Dell or a Lenovo machines. Or having different APIs to
> access the network depending on the machine vendor...
> 
> So I'm sorry, but I'm drawing a line in the sand here, unless you can
> come up with some really convincing NEW arguments why this needs to
> be a Dell specific interface, the Dell firmware-attributes code must
> use a generic sysfs-ABI/class to get accepted upstream.
> 
> Note that I think the currently suggested private Dell ABI is actually
> pretty suitable for such a generic sysfs-ABI/class, so I'm not asking
> you to make a lot of changes here.
> 
> Regards,
> 
> Hans

We'll try this for the v4 patch series.