From 0ca2fd0e2b18ae353e996ce48bb367d45c27eee0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Manuel=20P=C3=A9gouri=C3=A9-Gonnard?= Date: Fri, 12 Apr 2024 10:14:17 +0200 Subject: [PATCH] Update libtestdriver1 vs internal MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Manuel Pégourié-Gonnard --- .../testing/driver-interface-test-strategy.md | 14 +++++--------- 1 file 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 dfec4b3781..89f3c9b843 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