[flashrom] [RFC] Layout *file* handling...
dhendrix at google.com
Thu Jul 11 21:31:55 CEST 2013
On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner <
stefan.tauner at 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the flashrom