Re: [RFC PATCH 1/3] dtc: Add dtb build information option

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

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-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]