[flashrom] [RFC] Layout *file* handling...

[David Hendricks]

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).
>

Yay!


> 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.
>

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.


SGTM.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20130711/0c5a1be9/attachment.html>