-----Original Message----- From: Julius Werner jwerner@chromium.org Sent: 28 June 2019 02:01 To: Soby Mathew Soby.Mathew@arm.com Cc: tf-a@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: Header file re-org
Thanks Julius for the inputs. That makes sense. We already have a
precedence for sharing headers between the cross compiler and the host toolchain for the host tools via `tools_share` directory. Similarly we can have a `xxx_share` directory in /include for these headers. I think it is worth factoring out the U() macro to this folder. Regarding the __ASSEMBLY__ and AARCH32/AARCH64 macros, we could split the header out for asm, aarch32, aarch64 variants of the file thus removing the need to define these macros.
I tried factoring them out into different headers and have them include each other at first, but it didn't really work out and became a huge mess because they're so interdependent. entry_point_info_t is an architecture-dependent type that depends on param_header_t (an architecture-independent type), and they both have assembly-only constants associated with them. So in the end you would have to include bl_common_raw.h, bl_common_asm_raw.h, aarch64/ep_info_raw.h, aarch64/ep_info_asm_raw.h, param_header_raw.h and param_header_asm_raw.h all independently based on what macros are set. Maybe if I only split them up by architecture but not by asm/non-asm, that could work better.
Hi Julius Sorry for the delay in response. Yes, that would be good to separate atleast by Architecture but if it turns out to be messy we could keep the headers as they are.
For the assembly, btw, another option would be to use the macro __ASSEMBLER__ instead of __ASSEMBLY__. That is predefined by GCC and most other compilers (according to https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined- Macros.html#Standard-Predefined-Macros it's even part of a standard, although I can't find another source for that), so we could just assume that it will work in third-party projects as well and wouldn't need to do anything special for it. (If we want to do that, I think it would make sense to switch all TF-A code from __ASSEMBLY__ to __ASSEMBLER__ first. Do you know if there was a good reason you went with a custom-defined __ASSEMBLY__ in the first place?)
Hmm, I not sure for the reason for __ASSEMBLY__ instead of __ASSEMBLER__. I don’t see any reason why we shouldn't migrate to the standard macro. This can be done later.
I think these raw header are worth grouping together as it makes it clear the
need to handle them separately and makes it easier to export these headers. A strawman proposal for the header hierarchy :
/include/tf_share --> the ep_info, param_header and other such common
header could go in there
/include/tf_share/ bl_aux_params --> folder for the new bl_aux param
header
/include/tf_share/bl_aux_params/vendor/rockchip --> folder for vendor
extensions for the rockchip platform
Does that sound sensible ?
Yes, that sounds good. I would maybe suggest using "plat" instead of "vendor" to mirror the way the toplevel directories are structured better, so <share/bl_aux_params/plat/rockchip/plat_params.h> or maybe just <share/plat/rockchip/plat_params.h> instead. But I'm happy to follow whatever naming you prefer.
The most difficult part is finding suitable names 😊. How about `include/bl_handoff/plat` and `include/bl_handoff/bl_aux_params/plat` as the folders ?
Best Regards Soby Mathew