Dear Rasmus,
In message 20200219094726.26798-1-rasmus.villemoes@prevas.dk you wrote:
[1] Here's the current conditions for which these three drivers provide .save:
SPL U-Bootext4.c CONFIG_CMD_SAVEENV=y CONFIG_CMD_SAVEENV=y fat.c never CONFIG_CMD_SAVEENV=y sf.c never CONFIG_CMD_SAVEENV=y [2]
Some questions:
1) I'm not sure if your changes cover the situation that you want to have "saveenv" available in U-Boot proper, but do NOT want to have it in SPL. This may makie sense in situations where you need to be able to read the saved environment in SPL (say, to set up the configures console baud rate), but cannot affort the fule size resulting from adding "saveenv" etc.
It is mandatory that this possibility is kept.
2) It seems wrong to me to make such cleanup in any way dependent on file system type or a mix of arbitrary storage driver types. this should be handled in two independent, orthogonal steps: a) clean up any drivers or file system accessors that do not fit into the general model b) adapt the general model to such changes
Maybe it makes sense to change the order of these steps, if this results in less intrusive patches - I have no ides.
In any case testing must _also_ include all the other many ways of storing the environment, including parallel or SPI NOR flash, NAND flash, UBI, UNIFS, etc.
Best regards,
Wolfgang Denk