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

["Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>]

...
> > 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;
};

int do_something_VV(int operation, int item_count, struct item* list_of_items); ?

This way I can at give all parameters in one function call while still having the property of not having to know the actual data structure used in redboot.
And also consuming less code and less runtime and easier to understand logic (IMO).
One VV for: 
-version
-number of images
-erase entry
-create
-create with backup, maybe also just as a parameter to the one above
-changesDone  (close)
-get all fields for image i  (stat)

Without the last one I have to call 
noi=number_of_images()
for (i=0; i<noi; i++)
{
   n=get_name(i)             // <- this one has to be added
   l=get(name, id_data_length)  // <- exists already
   f=get(name, id_flash_base
   ...
}

with a combined call I can

noi=number_of_images()
for (i=0; i<noi; i++)
{
   get_all(i, list)       // <- this one has to be added
   //use data from list
}

which uses less code and less runtime, i.e. much less string comparisons and fis table iterations, and one new VV for retrieving the information by the index has to be added anyway.

Ok with you ?

Bye
Alex