Hi,
Although we've not completely thought through all the details, we suspect we will have to isolate each strong implementation under plat/common/ in a separate file such that platforms can pick and choose just the files (and thus, just the functions) they need.
[VW] It would be interesting to see if a function pointer based solution, similar to psci_ops, would be useful.
-Varun
-----Original Message----- From: Sandrine Bailleux sandrine.bailleux@arm.com Sent: Thursday, February 9, 2023 3:02 PM To: Varun Wadekar vwadekar@nvidia.com; tf-a tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Coding guidelines update: Discouraging usage of weak functions
External email: Use caution opening links or attachments
Hi Varun,
Thanks for the feedback.
On 2/9/23 15:54, Varun Wadekar wrote:
Hi,
Thanks for the initiative. I agree with it in principle but have some suggestions.
- We should allow platform owners to enforce or waive this policy for code that is encapsulated with a platform port. E.g one might choose to implement a plat/XX/common with weak functions and derive platforms ports from it. We should allow that.
I agree. I'll amend the patch in this regard.
- The strong implementation under plat/common needs to fine grained to allow platforms to use "just enough" instead of it being an "all or nothing" solution. Weak functions under plat/common allow us the flexibility to implement only the differences and still include other functionality form the same files. I'm afraid platform owners will lose this flexibility. This is a huge loss and should be carefully weighed before moving forward.
Yes, that's on our mind. Although we've not completely thought through all the details, we suspect we will have to isolate each strong implementation under plat/common/ in a separate file such that platforms can pick and choose just the files (and thus, just the functions) they need.
I agree that losing this flexibility would be unacceptable.
Happy to hear other implementation suggestions around that!
Best regards, Sandrine
-Varun
-----Original Message----- From: Sandrine Bailleux via TF-A tf-a@lists.trustedfirmware.org Sent: Thursday, February 9, 2023 2:31 PM To: tf-a tf-a@lists.trustedfirmware.org Subject: [TF-A] Coding guidelines update: Discouraging usage of weak functions
External email: Use caution opening links or attachments
Hi all,
As you may know, the TF-A project historically used to make heavy use of weak functions. The code base has numerous examples of them. However, based on previous discussions, I think we have general consensus in the TF-A community that the disadvantages of weak functions outweigh their benefits and for this reason we should discourage introducing new ones.
In practice, I think this policy is already enforced most of the time in code reviews but I've now posted a patch that makes it explicit in the project's coding guidelines and provide the rationale behind it.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi ew.trustedfirmware.org%2Fc%2FTF-A%2Ftrusted-firmware-a%2F%2B%2F19398&d ata=05%7C01%7Cvwadekar%40nvidia.com%7C09941ae389414c318a1808db0aae9fe9 %7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638115517348405152%7CUnk nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aJl2e5Tn9Tw4K99JAQsVSXtlzJ%2FYwQ GqAm1thAYK4ZU%3D&reserved=0
Note that TF-A maintainers would still be responsible for enforcing this policy, as the CI system won't flag that for them, mainly because I think there might be legitimate cases for weak functions in rare instances so we'd get some false positives from such checks.
We (at Arm) have got plans to gradually convert existing weak functions to strongly-defined implementations across the code base but this will take time.
Like I said, I don't expect this change to be too controversial but please raise any concerns you may have in this email thread or on Gerrit.
Best regards, Sandrine -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org