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