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