In psa_crypto_driver_wrappers.h, we define constants for each driver. They are used to dispatch to multipart operations. The constants are enumerated by counting starting at 1 in scripts/generate_driver_wrappers.py, based on the order in scripts/data_files/driver_jsons/driverlist.json.
/* BEGIN-driver id definition */
#define PSA_CRYPTO_MBED_TLS_DRIVER_ID (1)
#define MBEDTLS_TEST_OPAQUE_DRIVER_ID (2)
#define MBEDTLS_TEST_TRANSPARENT_DRIVER_ID (3)
#define P256_TRANSPARENT_DRIVER_ID (4)
/* END-driver id */
This is not a problem for integrators who run scripts/generate_driver_wrappers.py, and it's not a problem for integrators who replace psa_crypto_driver_wrappers.h by their own file. But it is a problem for integrators who patch the psa_crypto_driver_wrappers.h that we generate and ship in our release zips.
The goal of this task is to define a symbolic constant TF_PSA_CRYPTO_DRIVER_ID_MAX such that integrators who patch psa_crypto_driver_wrappers.h can assign their driver IDs as TF_PSA_CRYPTO_DRIVER_ID_MAX + 1 and onwards.
In
psa_crypto_driver_wrappers.h, we define constants for each driver. They are used to dispatch to multipart operations. The constants are enumerated by counting starting at 1 inscripts/generate_driver_wrappers.py, based on the order inscripts/data_files/driver_jsons/driverlist.json.This is not a problem for integrators who run
scripts/generate_driver_wrappers.py, and it's not a problem for integrators who replacepsa_crypto_driver_wrappers.hby their own file. But it is a problem for integrators who patch thepsa_crypto_driver_wrappers.hthat we generate and ship in our release zips.The goal of this task is to define a symbolic constant
TF_PSA_CRYPTO_DRIVER_ID_MAXsuch that integrators who patchpsa_crypto_driver_wrappers.hcan assign their driver IDs asTF_PSA_CRYPTO_DRIVER_ID_MAX + 1and onwards.