Update libtestdriver1 vs internal

Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>

1 files changed, 5 insertions, 9 deletions

diff --git a/docs/architecture/testing/driver-interface-test-strategy.md b/docs/architecture/testing/driver-interface-test-strategy.md
index dfec4b378..89f3c9b84 100644
--- a/docs/architecture/testing/driver-interface-test-strategy.md
+++ b/docs/architecture/testing/driver-interface-test-strategy.md
@@ -155,15 +155,11 @@ The drivers can use one of two back-ends:
   the build.
 
 Historical note: internal was initially the only back-end; then support for
-libtestdriver1 was added gradually.
-
-Question: if/when we have complete libtestdriver1 support, do we still need
-internal? Thoughts:
-- It's useful to have builds with both a driver and the built-in, in
-order to test fallback to built-in, but this could be achieved with
-libtestdriver1 too.
-  - Performance might be better with internal though?
-- The instrumentation works the same with both back-ends.
+libtestdriver1 was added gradually. Support for libtestdriver1 is now complete
+(see following sub-sections), so we could remove internal now. Note it's
+useful to have builds with both a driver and the built-in, in order to test
+fallback to built-in, which is currently done only with internal, but this can
+be achieved with libtestdriver1 just as well.
 
 Note: our test drivers tend to provide all possible entry points (with a few
 exceptions that may not be intentional, see the next sections). However, in