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 anyway. 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.
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) - 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) - Includes of other layout files (include .*) - Some kind of priority if one selects overlapping regions.
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.