[PATCH] tools: Remove #include <version.h>

Pali Rohár pali at kernel.org
Thu Feb 25 02:05:54 CET 2021


On Wednesday 03 February 2021 12:10:13 Pali Rohár wrote:
> On Monday 01 February 2021 16:20:18 Tom Rini wrote:
> > On Wed, Jan 27, 2021 at 04:34:24PM +0100, Pali Rohár wrote:
> > 
> > > Header file version.h includes also autogenerated file timestamp.h which
> > > is recompiled on every time when SOURCE_DATE_EPOCH change.
> > > 
> > > Tools do not use build time therefore they do not have to include
> > > timestamp.h file.
> > > 
> > > This change prevents recompiling tools every time when SOURCE_DATE_EPOCH
> > > changes.
> > > 
> > > Signed-off-by: Pali Rohár <pali at kernel.org>
> > > ---
> > >  tools/dumpimage.c  | 2 +-
> > >  tools/mkenvimage.c | 2 +-
> > >  tools/mkimage.c    | 2 +-
> > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/dumpimage.c b/tools/dumpimage.c
> > > index e5481435a7..54c2517c9e 100644
> > > --- a/tools/dumpimage.c
> > > +++ b/tools/dumpimage.c
> > > @@ -7,7 +7,7 @@
> > >  
> > >  #include "dumpimage.h"
> > >  #include <image.h>
> > > -#include <version.h>
> > > +#include "generated/version_autogenerated.h"
> > >  
> > >  static void usage(void);
> > >  
> > 
> > I don't know if I really like this approach.  It also seems inconsistent
> > as we have for example tools/fit-image.c that has content from
> > generated/version_autogenerated.h but wasn't changed by this patch (nor
> > the rest of the series).
> > 
> > I think a bit more invasive approach is required here.  I like the
> > <version_string.h> approach you used elsewhere, and as best I can see,
> > the only place U_BOOT_VERSION_STRING, which is where we have the
> > timestamp itself, is used is cmd/version.c (and defined in version.h).
> > We should isolate the file that has the date such that it's only
> > in one file and referenced in one file.  This means probably removing
> > the version_string global from arch/{powerpc,m68k} and dropping __weak
> > from cmd/version.c and seeing what happens, as well.
> 
> Hello! I have looked at dropping this weak property from version_string
> but seem it is not so easy... powerpc platforms have following code:
> 
> file arch/powerpc/cpu/mpc85xx/start.S:
> 
>        .globl  _start
> _start:
>        .long   0x27051956              /* U-BOOT Magic Number */
>        .globl  version_string
> version_string:
>        .ascii U_BOOT_VERSION_STRING, "\0"
> 
> I do not know how it is used, but for me it looks like that on these
> platforms is somehow null-term U-Boot version string important to be put
> after some magic number at specific location (start of the binary?).
> 
> How could we handle this situation? I do not have any of those powerpc
> platforms and I do not know any details about them.
> 
> If we cannot remove version string from this location, it is possible to
> tweak linker to put at this location version string from compiled
> cmd/version.o object file (at the time when building final u-boot
> binary)?
> 
> CCing powerpc maintainers.

Hello! Do you have any details? Can be version_string at beginning
dropped? Or it is required?

> 
> > Do you see where I'm thinking with this, or do I need to try and explain
> > a bit more?  Thanks!
> > 
> > -- 
> > Tom
> 
> 


More information about the U-Boot mailing list