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 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. Thanks for reviewing the whole series. -- Tom
signature.asc
Description: PGP signature
