From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sat, 26 Sep 2020 18:59:41 -0700 Subject: [PATCH v4 1/3] binman: Allow selecting default FIT configuration In-Reply-To: <95d2a41c-4de9-6e10-c4bc-2166f0bbd074@gmail.com> References: <95d2a41c-4de9-6e10-c4bc-2166f0bbd074@gmail.com> <20200906163910.18686-1-sjg@chromium.org> <20200906103901.v4.1.Ie75709c8b68c270e911bba4dbd521706c966087f@changeid> <7a121628-6fbd-0006-73dc-69b3993b6c53@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/09/2020 02:56, Simon Glass wrote: > On Tue, 8 Sep 2020 at 11:33, Alper Nebi Yasak 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!