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: ecos-devel at ecos dot sourceware dot org
- Date: Fri, 29 Oct 2004 12:58:54 +0200
- Subject: Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- References: <5A8A17126B73AC4C83968F6C4505E3C5013EEF81@JO-EX01.JENOPTIK.NET>
On Fri, Oct 29, 2004 at 12:43:55PM +0200, Neundorf, Alexander wrote:
> > > 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
> Ok, how about something like this:
> struct item
> int key;
> void* value;
Why do you need the key? Surely you know what is being passed to each
> int do_something_VV(int operation, int item_count, struct item* list_of_items); ?
O, I C. You want to do complex list manipulation rather than simply do
lots of calls. KISS.
> One VV for:
> -number of images
> -erase entry
> -create with backup, maybe also just as a parameter to the one above
I still don't see why you need this. Its just added complexity.
> -changesDone (close)
> -get all fields for image i (stat)
Stat only needs one field, the length. There is already a VV call to
return this. Might as well use it rather than add something new.
You seem to be missing
set entry point
which you need to call after doing a create. Plus