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

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

...
> > 
> > struct item
> > {
> >    int key;
> >    void* value;
> > };
> 
> Why do you need the key? Surely you know what is being passed to each
> VV call. 
> 
> > 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: 
> > -version
> > -number of images
> > -erase entry
> > -create
> > -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. 

I'm all for KISS.
Here I see KISS the other way round. With single calls I can mess around in various entries. If it is all combined in one call (create with all parameters) this is not possible.
If I have single calls the application can effectively modify the fis table as it wants to and create invalid entries. With having atomic functions which take all parameters at once this is not possible.
 
> > -changesDone  (close)
> > -get all fields for image i  (stat)
> 
> Stat only needs one field, the length.

...and the name. But sometimes the entry point and the crc might also be interesting.

> 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 length
> set entry point
> set flash_base
> 
> which you need to call after doing a create. Plus

"you need to call" from the application. If I don't call them or call them for other entries or .... a lot of things can go wrong. It is much easier if it is combined into one function call.

With the list they all can be given at once.
And with the list your main point, that the app doesn't have to care about the data structures used in redboot is fulfilled.

Bye
Alex