On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner <stefan.tauner@student.tuwien.ac.at> wrote:
This is slightly related to the write strategy discussion, so I'll
hijack its thread. While rebasing my layout patch set I rewrote the
layout file parser. It is now more flexible and it would be easy to
support more features. One feature it does already support are comments
starting with a # (anywhere in a line).

ATM it parses all previously valid layout files (AFAIK) and it should
continue to do so, even if they are not too common yet. We do not know
the exact numbers of usage, so breaking an unknown number of systems
does not seem like a good idea. We could and should provide a script
that converts 1.0 files to 2.0 syntax though. That should be trivial
One way to guarantee compatibility would be to have two modes of
operation in the parser and to mark layout 2.0 files somehow. This way
we could make sure that old formats are always handled correctly without
making it hard to add new features. The marks do not need to be backward
compatible IMHO (would be hard and/or awkward to do anyway because the
old format is so limited). So in case we need it I propose the
following mark:
Layout 2.0 files have to start with a comment in the first line
including "flashrom layout 2.0" (which is trivially implementable:
skipping whitespace till # in a loop, find the string with strstr
(and rewind)).

NB: Currently everything after the first space is considered the name of
the region. A typical line in 1.0 looks like this:
00009000:0003ffff normal
and it cant look much differently.

Things I definitely want to see in 2.0 files:
 - Comments. :)
 - Replacing mandatory hex with auto-detected address range bases.
   While probably everyone will use hex numbers I dont see a reason why
   we should enforce this. Converting 1.0 files by adding 0x in front
   of the addresses is easy to do too.

Sounds good. I think it also makes it easier to automatically generate layout files in scripts and such. CDH and I had a brief discussion about this here: http://www.flashrom.org/pipermail/flashrom/2010-November/005465.html .
Other possible features (just food for thought):
 - Default image names. For example one might want to always use me.bin
   for the ME region without the need to specify it all the time on the
   cli. (add the name after the region name, separated by : just like
   in the cli)

+1. It's pretty silly to need to specify a ROM-sized file for "-w" just to update a single region.
 - Default inclusion status. It would be nice to be able to mark some
   regions as to be included by default so that one does not even need
   to use -i. (no idea about syntax yet)

This one could get complicated... Maybe for the layout 2.0 you can add a column to specify include options like "always" or "never". That could be made into a comma-separated list with other region attributes (TBD).
 - Includes of other layout files (include .*)

Interesting! I like that idea.

 - Some kind of priority if one selects overlapping regions.

Interesting... Not sure I like it though. It seems too easy to botch this IMO.
Comments and further suggestions very welcome!

My current plan is to use the modified parser which parses the old
layout file without a problem but includes comments in my first batch
of layout patches. That consists mostly of the known patches to add
read, erase and verify support for layout files + that parser patch +
what else I can implement before the batch gets merged, but probably
without any other features discussed in here.


David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.