AW: contributing a failsafe update meachanism for FIS from within ecos applications

[Andrew Lunn]

On Fri, Oct 29, 2004 at 10:46:31AM +0200, Neundorf, Alexander wrote:
> > > which has to know all the fields required for creating a correct fis
> > > image, I don't see another way (except giving all parameter
> > > key-value based one by one to redboot, but I don't see a real
> > > difference: if a new redboot in the future should support additional
> > > informations, then an old application won't be able to supply these,
> > > no matter whether via key-value or this struct. Not being able to
> > > provide all parameters means not being able to provide then
> > > potentially essential new parameters and by this not being able to
> > > create correct images).
> > 
> > OK. How do you know when the applicaton and redboot are using the same
> > version of the structure? 
> 
> ...the same applies e.g. for the existing flash_cfg VV IMO.

True, but because one thing is not ideal does not mean you should
follow the pattern and add more problems.

> > By having individual setters you don't have this problem. You have one
> > VV which does "create a new FIS entry which name XYZ, and set the
> > other parameters to default values". You then have a number of VV
> > functions that allow you to set the other parameters one by one. If
> > somebody were to add a new parameter, no problem, it uses the default
> > value if the application does not set it. Once the application has set
> > everything it wants to set, it then calls the commit VV which actually
> > writes it to FLASH.
> 

> And you are sure that the new default parameter will always be what
> the user wants without any unexpected side effects ?

You can never be sure defaults will always suites every
application. But its better than doing completely the wrong thing
because the structure is different and will be wrongly interperted.
 
> I see it differently. Usually (e.g. linux, windows, ...) calls into
> libraries or calls into the kernel have a fixed interface. If the
> interface to the kernel changes, libc has to adapt to this
> change. If a function in libc changes, the application using this
> function has to be adapted. Now the developers (kernel, libc,
> others) do their best to avoid those changes.

> IMO this is the same what we are doing here. I really would want to
> make sure that the application which wants to write a new firmware
> image knows with which "interface version" of redboot it is working,
> and uses this interface correctly instead of relying on unknown
> default parameters.

Well, add a version VV. If the application finds reboot is running a
different version of the interface than what the application supports
it can then decide if it wants to accept the defaults, or simply abort
the upgrade.

        Andrew