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.
