On Mon, Jan 20, 2020 at 11:55:52AM -0700, Ian Lepore wrote:
> On Sun, 2020-01-19 at 16:39 +1000, David Gibson wrote:
> > On Fri, Jan 17, 2020 at 08:43:23AM -0600, Rob Herring wrote:
> > > On Fri, Jan 17, 2020 at 6:26 AM David Gibson
> > > <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Jan 16, 2020 at 09:58:23AM +0100, Alexandre Torgue wrote:
> > > > > Hi David
> > > > >
> > > > > [...]
> > > > >
> > > > > My first idea was to not modify all existing .dts files. Adding
> > > > > an extra option in dtc is (for me) the softer way to do it. I
> > > > > mean, compile information should come through compiler without
> > > > > modify .dts files outside from dtc. In this way it will be easy
> > > > > to everybody using dtc (inside our outside Linux tree) to add
> > > > > dtb build info (even if they don't how to write a dts file).
> > > >
> > > > But you're not really having this information coming from the
> > > > compiler. Instead you're adding a compiler option that just
> > > > force includes another file into the generated tree, and it's up
> > > > to your build scripts to put something useful into that file.
> > > >
> > > > I don't really see that as preferable to modifying the .dts
> > > > files.
> > > >
> > > > I also dislike the fact that the option as proposed is much more
> > > > general than the name suggests, but also very similar too, but
> > > > much more specific than the existing /incbin/ option.
> > > >
> > > > What might be better would be to have a dtc option which force
> > > > appends an extra .dts to the mail .dts compiled. You can then
> > > > put an overlay template in that file, something like:
> > > >
> > > > &{/} {
> > > > linux,build-info = /incbin/ "build-info.txt;
> > > > }
> > >
> > > I like this suggestion either as an include another dts file or an
> > > overlay.
> >
> > Sorry, to be clear what I'm talking about here is just including
> > another dts file, and using the compile-type overlay syntax. This is
> > not the same as .dtbo style runtime overlays (though the final result
> > is about the same in this case).
>
> Given that dts files are run through the C preprocessor before being
> fed to dtc, the build script could use the '-include' flag to force-
> include a fragment containing generated build info without any need to
> modify existing dts files.
Uh... maybe. -include will essentially prepend the forced file, which
is a bit awkward for our purposes. It means that the prepended file
would need the /dts-v1/ tag, and we couldn't have it in the main files
which would be a bit confusing. I think it would also cause problems
with any /memreserve/ tags and means that the main tree could in
theory overwrite the build information which we don't necessarily
want.
I guess we could build things the other way around: have the main .dts
file specified with -include and have the dts on the dtc commandline
be a fixed one with the build information. It'd be a little weird,
though.
> > > The latter could be useful as a way to maintain current dtb
> > > files while splitting the source files into base and overlay dts
> > > files.
> > >
> > > But no, let's not prepend this with 'linux'. It's not a property
> > > specific for Linux to consume.
> >
> > It's not really about who consumes it. It's about defining a
> > namespace for the new property to exist in, since it's not part of a
> > relevant standard (if we wanted to make it such, we should pin down
> > what goes in there with much more precision).
> >
> > This is specific to files built in the Linux tree, hence my
> > suggestion of "linux", whoever ends up consuming them.
> >
>
> I tend to agree with this. We use the dts files in freebsd, and if we
> wanted to include some build metadata, it would probably have different
> info in a different format than what linux uses. I would be inclined
> to add those as freebsd,build-info. As well as the namespace, this
> would give consumers some clue about what format the build info string
> might have.
>
> -- Ian
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
