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

Stefan Tauner stefan.tauner at student.tuwien.ac.at
Fri Jul 12 09:29:20 CEST 2013


On Thu, 11 Jul 2013 12:31:55 -0700
David Hendricks <dhendrix at google.com> wrote:

> On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner <
> stefan.tauner at student.tuwien.ac.at> wrote:
> 
> 
> >  - 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).

Maybe we should think more broadly about what we want to achieve. The
layout file as it is and the features I enumerated are very much
focused on describing attributes of address ranges. That is fine if it
is our main concern, but I am not sure it is.

Eventually we want to make it easier to describe access patterns to a
memory device, so maybe a more imperative approach would be better that
describes what flashrom should do. We would end up with a configuration
file that would be able to replace everything we can declare on the
command line now + current layout files + your write protection
commands + a schedule of what of the above should be used/done when.

The more I think about it the more I think this is wrong and way more
easily handled by real scipting languages together with a libflashrom
binding. :)

> >  - Includes of other layout files (include .*)
> >
> 
> Interesting! I like that idea.

Do you have use cases for that? We dont want to implement features just
because they sound nice to have :)

>  - Some kind of priority if one selects overlapping regions.
> 
> Interesting... Not sure I like it though. It seems too easy to botch this
> IMO.

Yes indeed. :) These ideas are a food for thought and nothing else. I
would like to get more feedback from the potential users regarding
(these) features and not invent stuff no one actually needs. As Stefan
wrote already the normal work flow is to get a complete image out of the
build system...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner




More information about the flashrom mailing list