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/?i...
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!