netdev - Re: [PATCH v6 13/13] 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: <10c2aa7d-eaa5-80f9-f831-7e31762ff149@gmail.com>
Date:   Tue, 8 May 2018 14:53:39 -0400
From:   Andres Rodriguez <andresx7@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>, gregkh@...uxfoundation.org
Cc:     andresx7@...il.com, 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, 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, ast@...com, hare@...e.com,
        jejb@...ux.vnet.ibm.com, martin.petersen@...cle.com, khc@...waw.pl,
        davem@...emloft.net, arve@...roid.com, tkjos@...roid.com,
        corbet@....net, mchehab+samsung@...nel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance
 and why we can't rename the module



On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote:
> Clarify the provenance of the firmware loader firmware_class module name
> and why we cannot rename the module in the future.
> 
> 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..a8047be4a96e 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 which registers a

Just a tiny repeated word here, "which which".

-Andres


> +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 compatibilty with old userspace.
>   
>   To load firmware using the sysfs interface we expose a loading indicator,
>   and a file upload firmware into:
>