Hi Julius OK, I agree using a more generic folder name is better. The suggested folder hierarchy is good. Regarding the name, `share` is a bit too generic IMO. How about the name `export` which brings in a bit more context regarding the contents in the folder ? Best Regards Soby Mathew
From: Julius Werner jwerner@chromium.org Sent: 03 July 2019 00:58 To: Soby Mathew Soby.Mathew@arm.com Cc: Julius Werner jwerner@chromium.org; tf-a@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: Header file re-org
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.
Sounds good, will do that (some time next week).
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 ?
I think it may be better to branch out the platforms right at the top level of the new namespace this is creating (e.g. include/<...>/plat/bl_aux_params, rather than include/<...>/bl_aux_params/plat), since that mirrors what the repository as a whole does more closely. Also, even if the current use case has both common and platform-specific headers, this may be useful for future use cases that are completely platform-specific, and for those having platform-specific top-level directories would work better.
I also think something generic (e.g. like you earlier suggested 'share') rather than something specific to this use case like 'bl_handoff' would be better, because it's more flexible for future use cases that may also want to do something similar. For example, imagine a platform that writes a data structure to memory or flash which is later parsed by a user space utility, and you want the user space utility to include TF's struct definitions for that rather than duplicate them... this has nothing to do with "bl_handoff", but it would still benefit from shareable headers like this.
That's why I suggested to structure it as 'include/share/plat/rockchip/...' and 'include/share/bl_aux_params/...'. Still, happy to use your scheme if you prefer.