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