Hi Alper,
On Thu, 3 Mar 2022 at 14:14, Alper Nebi Yasak <alpernebiya...@gmail.com> wrote:
>
> On 24/02/2022 01:59, Simon Glass wrote:
> > On Tue, 15 Feb 2022 at 04:53, Alper Nebi Yasak <alpernebiya...@gmail.com>
> > wrote:
> >> On 08/02/2022 21:50, Simon Glass wrote:
> >>> + fit,load
> >>> + Generates a `load = <...>` property with the load address of the
> >>> + segmnet
> >>> +
> >>> + fit,entry
> >>> + Generates a `entry = <...>` property with the entry address of
> >>> the
> >>> + ELF. This is only produced for the first entry
> >>> +
> >>> + fit,data
> >>> + Generates a `data = <...>` property with the contents of the
> >>> segment
> >>
> >> I think all these should be done by default. I don't see the point of
> >> not setting the properties, or setting them manually to values that will
> >> be the same for multiple nodes.
> >
> > My intent is to make things discoverable and obvious, so that magic
> > processing is explicit.
>
> OK then.
>
> >> Instead of putting these into the images subnode, we could have
> >> images-level subnodes for the operations. For example, instead of the
> >> above:
> >>
> >> images@gen-fdt-nodes {
> >> fdt-list = "of-list";
> >>
> >> fdt {
> >> type = "flat_dt";
> >> compression = "none";
> >> };
> >> };
> >
> > What does that mean, though? I presume it creates a second images {}
> > node, which is fine as dtc will merge them. But what about ordering?
>
> I imagined images@oper, configurations@oper would be binman-only control
> nodes that generate and append arbitrary nodes/entries inside whatever
> node name precedes the @oper. The meaning of what's inside the @oper
> nodes and what's generated would be solely defined by the operation.
>
> Honestly, I didn't think of ordering because I assumed it didn't matter
> inside FIT. It's a shortcoming of this design if it's important.
It doesn't matter for functionality but it is much nicer for the user
to have nodes and properties in a sensible order. That was one
motivation for the v2 series, since in v1 the node order was a mess.
>
> > I certainly prefer this in terms of elegance. I'm just not convinced
> > that people will understand it as well.
> >
> >>
> >> We can remove the -SEQ if we always append a sequence number, and we can
> >> set "description" to "NAME.dtb" when it's missing, or do the replacement
> >> when it's given. We can go further and use "%s", "%(name)s" or "{name}"
> >> instead of "NAME" for python-ish formatting and likewise for the
> >> sequence number.
> >
> > Yes, but again this adds more magic. For the Python formatting, we
> > still need to restrict what is put in there - e.g. we cannot just eval
> > an arbitrary varaible.
>
> Python only formats with what you give it (except for f-strings):
>
> >>> val = "test"
> >>> vals = {"name": "rk3399-gru-kevin", "seq": 1}
>
> >>> "conf-%(seq)d: %(name)s.dtb" % vals
> 'conf-1: rk3399-gru-kevin.dtb'
>
> >>> "%(val)s" % vals
> KeyError: 'val'
>
> >>> "conf-{seq}: {name}.dtb".format(**vals)
> 'conf-1: rk3399-gru-kevin.dtb'
>
> >>> "{val}".format(**vals)
> KeyError: 'val'
>
> But neither format style can go in a node name, so if you want the
> sequence number explicit in those I guess we're stuck with -SEQ and
> everything consistent with it.
Hmm yes that's a point.
>
> >>> [...]
> >
> > We should talk about this some more though. I'm a bit worried it will
> > get complaints about too much magic. I am trying to make it obvious
> > that nodes get generated in certain places.
>
> OK. I know I'm too biased towards magic, so won't insist much on those
> parts.
>
> > [...]
> >
> > Thanks for all the comments and ideas. I think this all need a little
> > more thought...
>
> I'll try replying to the v2 for the things changed in v2.
OK ta.
Regards,
Simon
