Re: [PATCH v4 10/22] lib: rspdm: Initial commit of Rust SPDM

[Alistair Francis]

On Thu, Oct 29, 2026 at 9:52 PM Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
>
> On Tue Oct 27, 2026 at 10:19 PM JST, Miguel Ojeda wrote:
> > On Tue, Oct 27, 2026 at 5:19 AM Alistair Francis <alistair23@xxxxxxxxx> wrote:
> >>
> >> That was kind of the goal with `SpdmState`. The issue is all of the
> >> drivers calling this (PCIe, NVMe, SATA and SCSI) are C drivers and
> >> won't be Rust for the foreseeable future. So there aren't any Rust
> >> users.
> >>
> >> I have improved things a lot with v5, let me know if you still want a
> >> Rust API. It just feels a bit silly to add one that will probably
> >> never be used.
> >
> > I mean, it is true that we don't want dead code, but in general we
> > would also want more Rust callers in the future -- so I guess it
> > depends on that "probably" you mention, i.e. how likely it is. So
> > could you please elaborate? i.e. why is it that you don't expect
> > future Rust callers? Would the NVMe Rust driver want to use this
> > eventually if merged? (Cc'ing Andreas)

You guys might have a better understanding them me.

For SPDM to work over a transport that transport needs a DMTF spec. So
right now SPDM will only work over PCIe, MCTP, NVMe/SCSI/ATA or TCP.

>From my (limited) understanding of the kernel's MCTP subsystem, SPDM
isn't going to happen in the kernel. I don't think there is a need for
TCP support either.

So that just leaves us with PCIe and the storage bindings. Both PCIe
and the storage transports have old well established C support in the
kernel. So those would need a Rust implementation to use the Rust API
for SPDM.

The NVMe Rust driver could use this! But that would have to be
accepted upstream first. From my outside view I thought that was still
a ways off.

>
> Yeah the "probably never be used" part sounds a bit strong to me, unless
> there is a reason I missed for why no Rust driver would ever want to use
> SPDM.

The "probably never be used" comes from having a Rust
re-implementation of PCIe or a storage driver.

>
> Regardless of that, I think it still makes sense to have a layered API
> design where the (necessarily unsafe) C API builds on top of a safe Rust
> API that enforces the invariants and other rules you want to uphold.
> That makes the invariants that C callers need to uphold manually clear,
> and avoids having C-isms in the Rust code (like we had with the crypto
> APIs calls in v4). Not to mention my favorite: it makes things easier to
> review. :)

Ok, I'll add a Rust API then

Alistair