[PATCH] image.h: Change android_image_get_dtb* to use uint and not u32

[Eugeniu Rosca]

Hello Yamada-san,

Thank you for your precious thoughts!

On Mon, Feb 17, 2020 at 04:45:57PM +0900, Masahiro Yamada wrote:
> If you need a fixed-width type,
> you can use uint32_t if you like.
> 
> It is already used.  See line 183 of include/image.h
> 
> typedef struct image_header {
>         uint32_t ih_magic; /* Image Header Magic Number */
> 
> include/compiler.h includes <stdint.h> when USE_HOSTCC is defined.

I think this is a safe, simple and non-intrusive solution,
so I have pushed https://patchwork.ozlabs.org/patch/1239098/.

> However, forbidding u32 for tools is questionable to me.

Since Linux has never restricted 'u32' in its in-tree tooling, I
totally support this statement.

> u32 and uint32_t should be always interchangeable.
> 
> Perhaps, does the following patch work?  (untested)
> --------------------->8------------------------
> diff --git a/include/compiler.h b/include/compiler.h
> index ed74c272b8c5..f2a4adfbc7e4 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -61,6 +61,9 @@
> 
>  #include <time.h>
> 
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
>  typedef uint8_t __u8;
>  typedef uint16_t __u16;
>  typedef uint32_t __u32;
> --------------------->8------------------------
> 

Since this has greater impact compared to s/u32/uint32_t/, I leave
up to Tom to decide on the most suitable approach.

> 
> BTW, I think include/compiler.h in U-Boot is ugly.
> 
> Linux kernel uses
> tools/include/linux/types.h
> for defining {u8,u16,u32,u64} for the tools space.
> 

Agreed, since below v3.16 commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d944c4eebcf4c0

> 
> Barebox also adopted a similar approach.
> 
> When compiling files for tools,
> <linux/types.h> actually includes
> scripts/include/linux/types.h
> instead of include/linux/types.h
> 
> 
> Perhaps, U-Boot could do similar,
> but I have never got around to it.
> 
> Maybe U-Boot shares too much code
> between U-Boot space and tooling space?
> 
> include/image.h of U-Boot is 1520 lines.
> include/image.h of Barebox is 258 lines.
> 
> But, I am not tracking how they diverged.
> 
> Shrinking the interface between U-Boot space and
> tooling space will provide a better maintainability.
> 
> ifdef would work. Perhaps, splitting the header might be even better.

The above sounds like food for thought on how to mitigate the problem
long-term.

> 
> That's my random thought.

Many thanks!

-- 
Best Regards
Eugeniu Rosca