[PATCH 0/5] CMD_SAVEENV ifdef cleanup

[Wolfgang Denk]

Dear Rasmus,

In message <20200219094726.26798-1-rasmus.villemoes at prevas.dk> you wrote:
>
> [1] Here's the current conditions for which these three drivers
> provide .save:
>
>           SPL                     U-Boot
> ext4.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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In a business, marketroids, salespukes, and  lawyers  have  different
goals from those who actually do work and produce something. Usually,
is  is the former who triumph over the latter, due to the simple rule
that those who print the money make the rules.
         -- Tom Christiansen in <5jdcls$b04$2 at csnews.cs.colorado.edu>