linux-kernel - [PATCH v7 14/14] Documentation: clarify firmware_class provenance and why we can't rename the module

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180510200850.5958-15-mcgrof@kernel.org>
Date:   Thu, 10 May 2018 13:08:50 -0700
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     gregkh@...uxfoundation.org
Cc:     akpm@...ux-foundation.org, keescook@...omium.org,
        josh@...htriplett.org, maco@...roid.com, andy.gross@...aro.org,
        david.brown@...aro.org, bjorn.andersson@...aro.org, teg@...m.no,
        wagi@...om.org, hdegoede@...hat.com, andresx7@...il.com,
        zohar@...ux.vnet.ibm.com, kubakici@...pl, shuah@...nel.org,
        mfuzzey@...keon.com, dhowells@...hat.com, pali.rohar@...il.com,
        tiwai@...e.de, kvalo@...eaurora.org, arend.vanspriel@...adcom.com,
        zajec5@...il.com, nbroeking@...com, markivx@...eaurora.org,
        broonie@...nel.org, dmitry.torokhov@...il.com, dwmw2@...radead.org,
        torvalds@...ux-foundation.org, Abhay_Salunke@...l.com,
        jewalt@...innovations.com, oneukum@...e.com,
        cantabile.desu@...il.com, khc@...waw.pl, arve@...roid.com,
        tkjos@...roid.com, corbet@....net, mchehab+samsung@...nel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-wireless@...r.kernel.org,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: [PATCH v7 14/14] Documentation: clarify firmware_class provenance and why we can't rename the module

Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.

Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
Reviewed-by: Kees Cook <keescook@...omium.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
---
 .../driver-api/firmware/fallback-mechanisms.rst          | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index a39323ef7d29..d35fed65eae9 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by
 associating the device used to make the request as the device's parent.
 The sysfs directory's file attributes are defined and controlled through
 the new device's class (firmware_class) and group (fw_dev_attr_groups).
-This is actually where the original firmware_class.c file name comes from,
-as originally the only firmware loading mechanism available was the
-mechanism we now use as a fallback mechanism.
+This is actually where the original firmware_class module name came from,
+given that originally the only firmware loading mechanism available was the
+mechanism we now use as a fallback mechanism, which registers a struct class
+firmware_class. Because the attributes exposed are part of the module name, the
+module name firmware_class cannot be renamed in the future, to ensure backward
+compatibility with old userspace.
 
 To load firmware using the sysfs interface we expose a loading indicator,
 and a file upload firmware into:
-- 
2.17.0