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]

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


On Thu, Oct 28, 2004 at 01:32:46PM +0200, Neundorf, Alexander wrote:
> For this I'd like to add a function which simply returns a pointer
> to the current valid fis table. Then this can be iterated (and
> modified) in "userspace".

I don't like that. You are spreading around the knowledge of what the
FIS image looks like, how you operate on it etc. Thats bad engineering
practice. There currently exists an abstraction on top of this which
does most of what you need. Just extend the abstraction a little.

> I didn't plan to open files for writing. They can only be opened for
> reading, and additionally there is a set of functions (eraseImage(),
> createImage()) which can modify the contents of the fis. If any file
> is opened when one of these functions is called, it returns with an
> error. IMO the fisfs shouldn't try to act like a real RW file
> system, for this we have jffs2, but like an RO file system,
> accompanied by some utility functions to update the contents of this
> RO filesystem.

I guess your createImage() call accepts the complete image. Many
systems don't have enought RAM to be able to hold the complete image
when doing an upgrade, but they do have enought RAM to hold one flash
block. What they want to do is download the new image from a server a
packet at a time and pass it to the filesystem to write to the
flash. The filesystem caches the writes until it has a complete flash
block and then writes it to flash.

How do you handle this case with your createImage() call?  

My solution seems much more natural if you are using the filesystem
metaphore.

> Well, actually mount() is the point where the interesting things
> happen, i.e. deciding which fis table to use I'd say.

Why. Redboot already knows that. Its just another example of you
wanting to spread around two copies of the same code into two
packages. That way leads to real maintinance problems, bugs etc.

        Andrew


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