
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.