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
| ||
|
Date: Wed, 9 May 2018 10:21:08 -0300 From: Mauro Carvalho Chehab <mchehab+samsung@...nel.org> To: "Luis R. Rodriguez" <mcgrof@...nel.org> Cc: gregkh@...uxfoundation.org, 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, 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, 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 Em Tue, 8 May 2018 11:12:47 -0700 "Luis R. Rodriguez" <mcgrof@...nel.org> escreveu: > 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 > +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. Ah, now the explanation makes a lot more sense to me :-) Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org> > > To load firmware using the sysfs interface we expose a loading indicator, > and a file upload firmware into: Thanks, Mauro
Powered by blists - more mailing lists