lib/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-07-29 11:41:15 +03:00
Code Activity

Update libtestdriver1 vs internal

Browse Source 
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit is contained in:
Manuel Pégourié-Gonnard
2024-04-12 10:14:17 +02:00
parent dde1abd572
commit 0ca2fd0e2b
1 changed files with 5 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/architecture/testing/driver-interface-test-strategy.md
View File

@ -155,15 +155,11 @@ The drivers can use one of two back-ends:
the build. the build.
Historical note: internal was initially the only back-end; then support for Historical note: internal was initially the only back-end; then support for
libtestdriver1 was added gradually. libtestdriver1 was added gradually. Support for libtestdriver1 is now complete
(see following sub-sections), so we could remove internal now. Note it's
Question: if/when we have complete libtestdriver1 support, do we still need useful to have builds with both a driver and the built-in, in order to test
internal? Thoughts: fallback to built-in, which is currently done only with internal, but this can
- It's useful to have builds with both a driver and the built-in, in be achieved with libtestdriver1 just as well.
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.
Note: our test drivers tend to provide all possible entry points (with a few 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 exceptions that may not be intentional, see the next sections). However, in