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: <Zf3J5wAgng8br6yd@makrotopia.org>
Date: Fri, 22 Mar 2024 18:11:51 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Bart Van Assche <bvanassche@....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 Fri, Mar 22, 2024 at 10:52:36AM -0700, Bart Van Assche wrote:
> 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.

Fine with me. I can implement such an interface, similar to how it is
implemented for MTD devices or UBI volumes for the block layer.

I would basically add a subscription and callback interface utilizing
a class_interface inside the block subsystem similar to how the same
is done in this series for registering block-device-backed NVMEM
providers.

However, given that this is a bigger task, I'd like to know from more
than one block subsystem maintainer that this approach would be
agreeable before spending time and effort in this direction.

Also note that obviously it would be much more intrusive and affect
*all* users of the block subsystem, while the current approach would
only affect those users who got CONFIG_BLOCK_NVMEM enabled.