linux-kernel - Re: [PATCH 4/8] block: implement NVMEM provider

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: <99874d1e-ff5c-4e8a-9922-752207119147@acm.org>
Date: Fri, 22 Mar 2024 10:52:36 -0700
From: Bart Van Assche <bvanassche@....org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
 Jens Axboe <axboe@...nel.dk>, Dave Chinner <dchinner@...hat.com>,
 Jan Kara <jack@...e.cz>, Thomas Weißschuh
 <linux@...ssschuh.net>, Damien Le Moal <dlemoal@...nel.org>,
 Li Lingfeng <lilingfeng3@...wei.com>, Christian Brauner
 <brauner@...nel.org>, Christian Heusel <christian@...sel.eu>,
 Min Li <min15.li@...sung.com>, Adrian Hunter <adrian.hunter@...el.com>,
 Avri Altman <avri.altman@....com>, Hannes Reinecke <hare@...e.de>,
 Christian Loehle <CLoehle@...erstone.com>, Bean Huo <beanhuo@...ron.com>,
 Yeqi Fu <asuk4.q@...il.com>, Victor Shih <victor.shih@...esyslogic.com.tw>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Dominique Martinet <dominique.martinet@...ark-techno.com>,
 "Ricardo B. Marliere" <ricardo@...liere.net>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
 linux-block@...r.kernel.org
Subject: Re: [PATCH 4/8] block: implement NVMEM provider

On 3/21/24 13:22, Daniel Golle wrote:
> On Thu, Mar 21, 2024 at 12:44:19PM -0700, Bart Van Assche wrote:
>> Why to add this functionality to the block layer instead of somewhere
>> in the drivers/ directory?
> 
> Simply because we need notifications about appearing and disappearing
> block devices, or a way to iterate over all block devices in a system.
> For both there isn't currently any other interface than using a
> class_interface for that, and that requires access to &block_class
> which is considered a block subsystem internal.

That's an argument for adding an interface to the block layer that
implements this functionality but not for adding this code in the block
layer.

Thanks,

Bart.