Hi Alexei,
On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote:
I'm wondering why we need to integrate libfdt sources in TF-A? Why cannot we use the same option as for MbedTls when the build system gets the path to the preloaded source tree?
As far as I know, the question is the other way around: why is mbed TLS not integrated in the TF-A source tree? If you look at the other external libraries used by TF-A (not just libfdt, but also compiler-rt library, zlib, ...), they all are integrated.
As far as I am aware, there are several reasons for keeping these projects in the TF-A tree:
1) It is more developer-friendly. Whenever you clone the TF-A repo, you get all required dependencies at the same time, no need to pull them yourself.
2) It allows us to keep local modifications on top of mainline. Such modifications are sometimes necessary or make our life easier to integrate/interface the project with the rest of the TF-A code base.
3) We don't depend on the library project infrastructure. For example if their git server is down, this would not affect us, as we've got our own copy hosted on tf.org. Not sure this third reason was actually considered at the time the decision was made but I see this as a tiny bonus.
Now 1) could be achieved some other way, for example we could add the dependent projects as git submodules and have a setup script that pulls them in. We did not go for this option at the time and I don't recall exactly why. It might just be because of the infrastructure/setup required to work with git submodules.
So having these projects integrated in the TF-A source tree is the common practice in our project. As far as I am aware, the reason why we treat mbed TLS differently is because it is very security sensitive, thus it's important that people keep up to date with the latest version to get all latest vulnerability fixes. If we had imported it in the TF-A project, this would have put the onus on us to monitor mbed TLS for security fixes and push updates as soon as they become available. This was deemed impractical and too much responsibility for us at the time.
Regards, Sandrine
Hi Sandrine,
Thanks for your very detailed explanation of the reason behind this solution. This brings the question on how do we monitor libfdt bug fixes, code cleanup, etc. (which Madhukar pointed out) and integrate these changes in TF-A source tree.
Regards.
Alexei
________________________________ From: Sandrine Bailleux Sandrine.Bailleux@arm.com Sent: 16 June 2020 08:38 To: Alexei Fedorov Alexei.Fedorov@arm.com; Madhukar Pappireddy Madhukar.Pappireddy@arm.com; Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library
Hi Alexei,
On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote:
I'm wondering why we need to integrate libfdt sources in TF-A? Why cannot we use the same option as for MbedTls when the build system gets the path to the preloaded source tree?
As far as I know, the question is the other way around: why is mbed TLS not integrated in the TF-A source tree? If you look at the other external libraries used by TF-A (not just libfdt, but also compiler-rt library, zlib, ...), they all are integrated.
As far as I am aware, there are several reasons for keeping these projects in the TF-A tree:
1) It is more developer-friendly. Whenever you clone the TF-A repo, you get all required dependencies at the same time, no need to pull them yourself.
2) It allows us to keep local modifications on top of mainline. Such modifications are sometimes necessary or make our life easier to integrate/interface the project with the rest of the TF-A code base.
3) We don't depend on the library project infrastructure. For example if their git server is down, this would not affect us, as we've got our own copy hosted on tf.org. Not sure this third reason was actually considered at the time the decision was made but I see this as a tiny bonus.
Now 1) could be achieved some other way, for example we could add the dependent projects as git submodules and have a setup script that pulls them in. We did not go for this option at the time and I don't recall exactly why. It might just be because of the infrastructure/setup required to work with git submodules.
So having these projects integrated in the TF-A source tree is the common practice in our project. As far as I am aware, the reason why we treat mbed TLS differently is because it is very security sensitive, thus it's important that people keep up to date with the latest version to get all latest vulnerability fixes. If we had imported it in the TF-A project, this would have put the onus on us to monitor mbed TLS for security fixes and push updates as soon as they become available. This was deemed impractical and too much responsibility for us at the time.
Regards, Sandrine
Hi Alexei,
On 6/16/20 1:51 PM, Alexei Fedorov wrote:
Thanks for your very detailed explanation of the reason behind this solution. This brings the question on how do we monitor libfdt bug fixes, code cleanup, etc. (which Madhukar pointed out) and integrate these changes in TF-A source tree.
Right now, it is a manual process and not only for libfdt but for all projects TF-A depends on. We keep an eye on them and aim at updating them when necessary. Unfortunately, like any manual process, it is error-prone and things might slip through the cracks. The TF-A release tick is usually a good reminder to update all dependencies but unfortunately libfdt has been left behind for some time (about 2 years)...
Regards, Sandrine
tf-a@lists.trustedfirmware.org
-
Alexei Fedorov -
Sandrine Bailleux