<div dir="ltr">On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner <span dir="ltr"><<a href="mailto:stefan.tauner@student.tuwien.ac.at" target="_blank">stefan.tauner@student.tuwien.ac.at</a>></span> wrote:<br><div class="gmail_extra">

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is slightly related to the write strategy discussion, so I'll<br>


hijack its thread. While rebasing my layout patch set I rewrote the<br>
layout file parser. It is now more flexible and it would be easy to<br>
support more features. One feature it does already support are comments<br>
starting with a # (anywhere in a line).<br></blockquote><div><br></div><div>Yay!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

ATM it parses all previously valid layout files (AFAIK) and it should<br>
continue to do so, even if they are not too common yet. We do not know<br>
the exact numbers of usage, so breaking an unknown number of systems<br>
does not seem like a good idea. We could and should provide a script<br>
that converts 1.0 files to 2.0 syntax though. That should be trivial<br>
anyway.<br>
One way to guarantee compatibility would be to have two modes of<br>
operation in the parser and to mark layout 2.0 files somehow. This way<br>
we could make sure that old formats are always handled correctly without<br>
making it hard to add new features. The marks do not need to be backward<br>
compatible IMHO (would be hard and/or awkward to do anyway because the<br>
old format is so limited). So in case we need it I propose the<br>
following mark:<br>
Layout 2.0 files have to start with a comment in the first line<br>
including "flashrom layout 2.0" (which is trivially implementable:<br>
skipping whitespace till # in a loop, find the string with strstr<br>
(and rewind)).<br>
<br>
NB: Currently everything after the first space is considered the name of<br>
the region. A typical line in 1.0 looks like this:<br>
00009000:0003ffff normal<br>
and it cant look much differently.<br>
<br>
Things I definitely want to see in 2.0 files:<br>
 - Comments. :)<br>
 - Replacing mandatory hex with auto-detected address range bases.<br>
   While probably everyone will use hex numbers I dont see a reason why<br>
   we should enforce this. Converting 1.0 files by adding 0x in front<br>
   of the addresses is easy to do too.<br></blockquote><div><br></div><div>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: <a href="http://www.flashrom.org/pipermail/flashrom/2010-November/005465.html">http://www.flashrom.org/pipermail/flashrom/2010-November/005465.html</a> .</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Other possible features (just food for thought):<br>


 - Default image names. For example one might want to always use me.bin<br>
   for the ME region without the need to specify it all the time on the<br>
   cli. (add the name after the region name, separated by : just like<br>
   in the cli)<br></blockquote><div><br></div><div>+1. It's pretty silly to need to specify a ROM-sized file for "-w" just to update a single region.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


 - Default inclusion status. It would be nice to be able to mark some<br>
   regions as to be included by default so that one does not even need<br>
   to use -i. (no idea about syntax yet)<br></blockquote><div><br></div><div>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).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - Includes of other layout files (include .*)<br></blockquote><div><br></div><div>Interesting! I like that idea.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


 - Some kind of priority if one selects overlapping regions.<br></blockquote><div><br></div><div>Interesting... Not sure I like it though. It seems too easy to botch this IMO.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Comments and further suggestions very welcome!<br>
<br>
My current plan is to use the modified parser which parses the old<br>
layout file without a problem but includes comments in my first batch<br>
of layout patches. That consists mostly of the known patches to add<br>
read, erase and verify support for layout files + that parser patch +<br>
what else I can implement before the batch gets merged, but probably<br>
without any other features discussed in here.</blockquote><div><br></div><div>SGTM. <br></div></div><div><br></div>-- <br>David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.
</div></div>