This is the mail archive of the
mailing list for the eCos project.
Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- From: Andrew Lunn <andrew at lunn dot ch>
- To: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>, ecos-devel at ecos dot sourceware dot org
- Date: Fri, 29 Oct 2004 12:03:55 +0200
- Subject: Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- References: <5A8A17126B73AC4C83968F6C4505E3C5013EED88@JO-EX01.JENOPTIK.NET>
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