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

[Alexandre Courbot]

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)

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.

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. :)