This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi,

> Von: ecos-devel-owner@sources.redhat.com
> Now creat() is tricky. You don't know enough in the application to
> reliably create new entries. Using the filesystem metaphore you don't
> know where files are stored on the storage medium. So how can you pick
> the empty space? Maybe somebody has used the serial port and added a
> new FIS entry which your application does not know about? You then
> create the new one right in the middle? The only simple way around
> this is to ask redboot to allocate the space. You set the data_length
> field and then ask redboot to find an empty location big enough. This
> might work, or it might not. And when it does not, you are in
> trouble. So i think create is fundementaly unreliable unless its done
> from the redboot prompt by a human.

Ok. That's why I want to give the create (or set_config) function basically the same parameters a human at a prompt would give, i.e. everything manually and inside only checking that nothing overlaps.
 
> Now having said that, if i were to implement create, which i would
> not, i would implement the creation of a FIS entry using
> cyg_io_set_config(). I suggest you read the source code and work out
> how that works. (This is one place you can pass a structure, since its
> internal to the application.)

Ok.
 
...
> > 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.
 
> 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 ?

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.
(that's why several people don't like the ioctl()-style functions in the linux kernel and are trying to reduce their number or at least not to increase their number too much).

So I would say a firmware which wants to use fis for writing from applications has to use the same fis version as the underlying redboot does. It should fail with an assertion if the versions don't match. The version matching could be done by changing to a new value for the VV operation.
If you really think that this is not required I can implement the key-value scheme but I don't think it would be the better way. (after all the interface doesn't change so often, fis.h has currently version 1.6)

Bye
Alex


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]