Alistair Francis wrote: > This is the initial commit of the Rust SPDM library. It is based on and > compatible with the C SPDM library in the kernel (lib/spdm). > > Signed-off-by: Alistair Francis <alistair@xxxxxxxxxxxxx> [..] > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > index 690a2a38cb52..744d35d28dc7 100644 > --- a/drivers/pci/Kconfig > +++ b/drivers/pci/Kconfig > @@ -128,7 +128,7 @@ config PCI_CMA > select CRYPTO_SHA256 > select CRYPTO_SHA512 > select PCI_DOE > - depends on SPDM > + depends on SPDM || RSPDM > help > Authenticate devices on enumeration per PCIe r6.2 sec 6.31. > A PCI DOE mailbox is used as transport for DMTF SPDM based > diff --git a/lib/Kconfig b/lib/Kconfig > index 4db9bc8e29f8..a47650a6757c 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -754,6 +754,23 @@ config SPDM > in .config. Drivers selecting SPDM therefore need to also select > any algorithms they deem mandatory. > > +config RSPDM > + bool "Rust SPDM" > + select CRYPTO > + select KEYS > + select ASYMMETRIC_KEY_TYPE > + select ASYMMETRIC_PUBLIC_KEY_SUBTYPE > + select X509_CERTIFICATE_PARSER > + depends on SPDM = "n" I trust these last 2 diff hunks never actually go upstream, right? I.e. if the kernel has no SPDM today it should not plan to carry 2 implementations just for language differences. I am not sure if that is already the plan, but the cover letter seemed ambiguous with its "maintaining compatibility" statement. On one hand, that does not make sense when this is brand new upstream code (i.e. C version is not even in linux-next), and there are no chances for regressions. Just embrace the attempt to be a Rust library for C consumers or otherwise help the C version along. However, if "maintain compatibility" means "make it easy for the work-in-progress C-effort to switch dependencies", then that makes sense and is worth clarifying in the next posting.
