Re: [PATCH 2/2] rust: scatterlist: honor the device's maximum segment size

[Alexandre Courbot]

On Tue Sep 29, 2026 at 12:05 AM JST, Alexandre Courbot wrote:
> On Mon Sep 28, 2026 at 7:44 AM JST, Matteo Kloiber wrote:
>> First of all, thanks for merging my first two patches and sorry about my late reply.
>>
>> What I think Alex meant and what I agree with is that the new API should focus on
>> making semantic bugs harder, not to necessarily make it easier to write safer
>> drivers. That being said, I think we can do both with this change.
>>
>> The key change here is that we introduce a structure that defines dma
>> parameters for a device. This structure deliberately has no default
>> implementation and new fields should be added even if they require changes for
>> all dma drivers.
> <...>
>
> Thanks for the detailed plan; I think it mostly makes sense.
>
> A few details that we have discussed offline with Danilo:
>
> - The `probe` methods should not take the `dma::Setup` token directly,
>   but rather a bus-specific struct that contains it and can be augmented
>   with other capabilities. Drivers would have to deconstruct it using
>   the `..` operator to make sure code doesn't break if we add new tokens
>   to it.
> - The token should not assume default parameters and only call functions
>   corresponding to parameters explicitly set; converting the token to a
>   handler means the driver acknowledged all the settings, so we should
>   not make any parameter mandatory (the doc should of course detail what
>   drivers *should* do).
>
> With that and your plan I believe you have a solid basis to send a
> RFC/PoC. :)

Stumbled upon the notes I took while discussing with Danilo so sharing
the extra info that was there:

- As a consequence of this, the `DmaDevice` trait is likely to go away.
- The name of the capabilities struct is not clear yet, but something
  like `pci::InitTokens` could work (because it would only contain such
  tokens that reference the device).