On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner <
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
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
NB: Currently everything after the first space is considered the name of
the region. A typical line in 1.0 looks like this:
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
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
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
> 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.