[flashrom] [PATCH 2/4] layout: Add -i <image>[:<file>] support.

[Stefan Tauner]

On Tue, 17 Sep 2013 10:55:37 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Am 16.09.2013 15:52 schrieb Stefan Tauner:
> > On Mon, 16 Sep 2013 03:36:47 +0200
> > Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >
> >> Am 16.09.2013 02:40 schrieb Stefan Tauner:
> >>> On Mon, 16 Sep 2013 00:46:48 +0200
> >>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >>>
> >>>> Am 15.09.2013 20:14 schrieb Stefan Tauner:
> >>>>> On Sun, 15 Sep 2013 04:15:44 +0200
> >>>>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >>>>>
> >>>>>> Am 12.09.2013 22:40 schrieb Stefan Tauner:
> > 
> > Regarding ROM I have the same problems here as above in "ROM layout",
> > although here it is less severe, because it does not allow for so many
> > interpretations with the given context. So I think I could very well
> > live with "ROM image" for VFRTFCC and "ROM image file" for the files
> > named by -r/-w/-v parameters. I would still prefer an alternative if we
> > can come up with one that. chip (or flash) image (file), complete or
> > (full) image (file), chip/flash content (file), ...
> 
> Maybe someone else can weigh in. Otherwise I'd say we use what we have
> at this point in the discussion.

David?

> >> What about "partial image" or "region image" for files specified with
> >> --include region:file?
> > For those the image problem stated above is not so severe, but we
> > should distinguish them too to aid understanding of the differences of
> > the whole-chip images vs. files, else region image would be fine.
> 
> sub-image? chunk image? region image? partial image? Lots of possible
> names come to mind. "region image file" has the advantage of making it
> clear that we're dealing with a file, and that it has something to do
> with regions.

As I tried to explain, I have no problem with the "region image" apart
from the image/file ambiguity. "region image file" is totally fine with
me.

>  
> >>> But anyway, your sentence still implies that the file given in -w is
> >>> modified and that's what I was concerned about actually. No idea why I
> >>> brought up the file-less -w at all (anymore) sorry.
> >> I see. Not sure how to express that best. Next try:
> >> This allows replacing the contents of one ROM image region with contents
> >> from another file before writing the resulting contents to the flash
> >> chip, eliminating the separate step of manually assembling a combined
> >> ROM image.
> > Not sure if one would understand the subtle difference without knowing
> > it beforehand. I think the use of region there might even confuse more
> > than it helps. The context of this sentence is the explanation of
> > the :<file> parameter for --include:
> > The optional
> > .B file
> > parameter specifies the name of a file that is used to map the contents of that very region only.
> 
> That's also not really an optimal way to express the parameter. Strictly
> speaking, the file is not used to map contents of the region, but the
> other way round (mostly).

Hm well, are memory mapped files a map of memory or is the memory a map
of the file...? For bijective maps (aka functions) there is usually a
trivial reverse map - so to me "file maps regions" and "region maps
file" are synonymous. NB: I don't use the preposition "to" at all, which
might give a hint of the direction of the function. But of course one
can read the subject and object of the sentence as direction hint too.
Being terse and unambiguous is hard :)

> > What about this:
> > This allows the contents of a part of the $romimage to be overlayed with
> > content from another file when writing.
> 
> Mh. How about:
> The optional file parameter causes the contents of this region to be
> replaced by the contents of the file specified here.

That's fine for the current -w-only case and I'll add it to this patch,
but we will need a longer explanation for the future cases.

> > We need to change that part of the documentation anyway when we add -r
> > and -v support for --include.
> 
> Right. This also means we have to disallow --include for -r until -r
> support is in. Does it even make sense to support --include for -v?

In general, sure why not? If you want to make sure that the bootblock
is fine only, or if you know only half the flash contains useful data
and dont care if the rest is erased or not...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner