[PATCH v4 1/3] binman: Allow selecting default FIT configuration

[Simon Glass <sjg@chromium.org>]

On 09/09/2020 02:56, Simon Glass wrote:
> On Tue, 8 Sep 2020 at 11:33, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>> I might be too late to say this but the SEQ thing looks ugly to me.
>> Maybe there could be some generic control-flow-like nodes that could
>> generate and insert things in their own place. If it makes sense, I'm
>> imagining something like:
>>
>>     fit {
>>         images {
>>             __for__ {
>>                 for,variable = "name";
>>                 for,in-args = "of-list";
>>
>>                 fdt-#name {
>>                     description = "fdt-$name.dtb";
>>                     type = "flat_dt";
>>                     compression = "none";
>>                 };
>>             };
>>         };
>>
>>         configurations {
>>             __for__ {
>>                 for,variable = "name"
>>                 for,in-args = "of-list";
>>
>>                 __if__ {
>>                     if,arg-equals = "default-dt", "$name";
>>                     default = "config-#name";
>>                 };
>>
>>                 config-#name {
>>                     description = "conf-$name.dtb";
>>                     fdt = "fdt-#name";
>>                 };
>>             };
>>         };
>>     };
>
> I certainly like the flexibility of this and I fiddled with something
> similar (without the __if__ as I didn't have 'default support) before
> going with a hard-coded approach. I agree what I have is ugly and I'm
> pleased to get some feedback.
>
> I think we could use _for instead of __for__.

That works too, I just wanted it to feel very out-of-place as a node
name and that was the first thing to pop into my mind.

> For $name I avoided that because it only works if there is a
> non-character afterwards, e.g. $namex is ambiguous. I briefly played
> with ${name} and {name} but ended up with the ugly capitals.

I was thinking that it'd only substitute the thing in "for,variable" so
it wouldn't be ambiguous, but indeed ${name} is better.

> The biggest question in my mind is whether we want our device-tree
> templates to be turing-complete. It seems nice but I feel that what
> you have above is much harder to understand and get right.

That's true. At least, better to put it off until it's needed in other
places and then attempt a proper design. I'm not sure that something
like this has to be turing-complete to be useful, though it could easily
end up turing-complete by accident.

Applied to u-boot-dm/next, thanks!