On Fri, Jun 19, 2020 at 02:40:06PM +0000, Patrick DELAUNAY wrote: > Hi, > > > From: Tom Rini <tr...@konsulko.com> > > Sent: jeudi 18 juin 2020 21:17 > > > > On Tue, Jun 16, 2020 at 09:40:44AM +0200, Patrick Delaunay wrote: > > > > > Add support of environment location with a new sandbox command > > > 'env_loc'. > > > > > > When the user change the environment location with the command > > > 'env_loc <location>' the env is reinitialized and saved; the > > > GD_FLG_ENV_DEFAULT flag is also updated. > > > > > > When the user set the same env location, the environment is re-loaded. > > > > > > Signed-off-by: Patrick Delaunay <patrick.delau...@st.com> > > > --- > > > > > > Changes in v2: > > > - change cmd_tbl_t to struct cmd_tbl > > > > > > board/sandbox/sandbox.c | 42 > > > ++++++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 41 insertions(+), 1 deletion(-) > > > > This is for testing, which is why it's on sandbox? But I think we should > > have this > > be a generic opt-in feature as changing where environment is saved at run > > time > > has use cases when we have multiple available. Thanks! > > Yes in my mind it was only for testing on sandbox.... > > But I agree, I can a add a opt-in generic command to select and load ENV on > one target. > > Someting as "env load [<target>] " which loads with the request backend and > update gd->env_load_prio > > With <target> = name of the name define in backend with ENV_NAME macro > And using the default location gd->env_load_prio when absent. > > Or split in 2 new commands > > - env select <target> > - env load > > Perhaps this last proposal with 2 command is more flexible.... > to be combined with other command (env save / env erase) > > if this proposal is OK, I will work on it.....
Sounds good to me, thanks! -- Tom
signature.asc
Description: PGP signature
