Move to an additive configuration mechanism #8107
Labels
api-break
This issue/PR breaks the API and must wait for a new major version
component-platform
Portability layer and build scripts
enhancement
size-l
Estimated task size: large (2w+)
The configuration mechanism inherited from PolarSSL to specify which modules are included is exact: the user has to list the modules that they want, as well as the dependencies of those modules. This is a problem for users because they have to traverse the dependency tree manually. This is a problem for maintainers because we can't change dependencies since that would break user code. This is also a problem for maintainers because it's harder to construct test configurations, especially when enumerating them automatically (as in
depends.py
).Over time, we've deviated from this principle in order to preserve backward compatibility. For example,
MBEDTLS_SSL_CLI_C
requiresMBEDTLS_SSL_TLS_C
becausessl_cli.c
calls functions inssl_tls.c
. When we split some code fromssl_tls.c
intossl_msg.c
, we did not add a configuration optionMBEDTLS_SSL_MSG_C
because that would have broken every application that has its ownconfig.h
: we continued to gate the code inssl_msg.c
withMBEDTLS_SSL_TLS_C
. But really,MBEDTLS_SSL_TLS_C
should just be an internal symbol defined whendefined(MBEDTLS_SSL_CLI_C) || defined(MBEDTLS_SSL_SRV_C)
, it isn't something the library users should be concerned with.PSA crypto uses an additive configuration mechanism: the user specifies the features they want (
#define PSA_WANT_xxx 1
), and it's the library's job to include all the code that's necessary to provide those features. Users don't have to care how the features are implemented.The goal of this issue is to move all configuration to a new mechanism that's similar to PSA crypto. If A requires B then activating A should activate B under the hood.
This can be done in a minor release, but the new mechanism would have to coexist with the old one, since we can't get rid of the old one. So it's easier to do in a major release.
There will still be a few invalid configurations: when A requires (B1 or B2 or B3), it may be an error to enable A but none of the B's (e.g. enabling TLS but not enough cryptographic mechanisms for any cipher suite). But this should be rare.
Note that feature configuration must rely only on the C preprocessor, because there are prominent users who use tools that edit lists of
#define
statements in a file in a BSP. We can provide other mechanisms, but list-of-define must work.The text was updated successfully, but these errors were encountered: