[PATCH 6/6] block: Remove "select BLK" from non-block drivers

[Quentin Schulz]

Hi Tom,

On 1/14/25 5:59 PM, Tom Rini wrote:
> On Tue, Jan 14, 2025 at 02:53:48PM +0100, Quentin Schulz wrote:
>> Hi Tom,
>>
>> On 12/20/24 11:22 PM, Tom Rini wrote:
>>> Now that block drivers are all selecting the BLK symbol, there's no need
>>> for other options to be select'ing BLK so that other required
>>> functionality can be enabled. Remove these places.
>>>
>>
>> We have multiple commands depending on the BLK symbol.
> 
> Yes.
> 
>> BOOTSTD also depends on it, but I assume we should be able to network boot
>> without HW block drivers?
> 
> Correct. That's part of the motivation for this series (which I wasn't
> clear enough about on its own). Without something like this series if we
> remove the BLK dependency from BOOTSTD then some other platforms fail to
> build or grow a bunch in size (as BOOTSTD is default y and now it's
> enabled on those platforms).
> 
>> CMD_UFETCH wouldn't be usable without those drivers as well.
>>
>> Should we do something about that by making them not depend on BLK e.g. use
>> CONFIG_IS_ENABLED in the right places? Not sure if all devicess based on
>> those archs have at least one HW block driver enabled. I guess checking if
>> all .config before and after that change are identical would help us figure
>> out if this could introduce a regression?
> 
> There's a few options, depending on what the command is. For CMD_UFETCH
> it's likely that a small restructure would be needed to not try and

My point is that I believe this patch is too hastily removing the select 
BLK because some symbols have "depends on BLK" and by removing the 
select, we make those symbols unselectable. This can cascade if other 
symbols depend on those now unselectable symbols.

Also, removing the select BLK from architecture/target symbols can 
introduce regressions if BLK really is required?

I think a reasonable (albeit cumbersome) solution is to migrate all 
those selects to the impacted defconfigs so that effectively no change 
is made for existing devices. If maintainers want to remove BLK, they 
could then do it later.

This also makes sure that BOOTSTD and CMD_UFETCH (and others) are still 
enabled, since BLK would still be enabled, just from a different 
location. Then another patch series could remove BOOTSTD dependency on 
BLK by adapting the code, same for CMD_UFETCH (and others).

Does this make sense? Am I missing something?

> print block devices while preserving the rest of the formatting. For
> CMD_LSBLK / CMD_CLONE it's an unfortunate short-hand for "some block
> device exists" which is functionally what those commands require.
> 

Yes, we need to keep the depends on BLK for those.

Cheers,
Quentin