[U-Boot] [PATCH 5/6] cmd_nvedit.c: allow board-specific code before/after saving the environment

[Timur Tabi]

Mike Frysinger wrote:
> On Friday 04 May 2012 18:21:31 Timur Tabi wrote:
>> Introduce board_start_saveenv() and board_finish_saveenv(), two "weak"
>> functions that are called before and after saving the environment.  This
>> allows for board-specific functions that "prepare" the board for saving
>> the environment.  This is useful if, for some reason, the non-volatile
>> storage is normally unavailable (e.g. blocked via a mux).
> 
> all these board hooks are paper-cutting us to death with unused bloat

I know, and I don't like it either.  I hate how our hardware designers are
always breaking the "rules", forcing us software developers to hack up our
software more and more.  The muxing on this chip is a like a cruel joke
being played on me.  I've even been told that I'm trying too hard to make
it work.

> this is less bloat:
> int board_start_saveenv(void) __attribute__((weak, alias("saveenv")));
> 
> int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> 	printf("Saving Environment to %s...\n", env_name_spec);
> 	return board_saveenv() ? 1 : 0;
> }

Ah, I see.  This forces the board-specific function to call saveenv().
That gives us more flexibility in the board code.

However, I was trying to mimic what we have in the NAND layer, with
nand_get_device() and nand_release_device().  That is, before we save the
environment, we have to "get" it, and then after we save it, we can
"release" it.

Your approach, although it eliminates two weak functions, is not as
"architecturally clean" as mine, IMHO.

I'm happy to do it your way if that's the consensus.  I just want everyone
to understand my approach first.

-- 
Timur Tabi
Linux kernel developer at Freescale