# Meeting 2025-07-09
<!-- Leave your topic starting with ### in the relevant sections below -->

## Critical
<!-- bugs, soundness issues, urgent patches/reviews etc. -->

## Status Reports
<!-- You want to report on something you are working on/request reviews.
Or you want to know the status of something someone else is doing -->

## Discussion Questions
<!-- Anything that requires lengthy discussion/more general questions also fit here -->

### DMA mask accessors

Link: https://lore.kernel.org/lkml/[e-mail]/

rust/kernel/dma.rs

/// Trait to be implemented by bus specific devices.
///
/// The [`dma::Device`](Device) trait should be implemented by bus specific device representations,
/// where the underlying bus is DMA capable, such as [`pci::Device`](::kernel::pci::Device) or
/// [`platform::Device`](::kernel::platform::Device).
pub trait Device: AsRef<device::Device<Bound>> {
    /// Inform the kernel about the device's DMA addressing capabilities.
    ///
    /// Set both the DMA mask and the coherent DMA mask to the same value.
    ///
    /// Note that we don't check the return value from the C `dma_set_coherent_mask` as the DMA API
    /// guarantees that the coherent DMA mask can be set to the same or smaller than the streaming
    /// DMA mask.
    fn dma_set_mask_and_coherent(&self, mask: u64) -> Result {
        // SAFETY: By the type invariant of `device::Device`, `self.as_ref().as_raw()` is valid.
        to_result(unsafe { bindings::dma_set_mask_and_coherent(self.as_ref().as_raw(), mask) })
    }

    /// Same as [`Self::dma_set_mask_and_coherent`], but set the mask only for streaming mappings.
    fn dma_set_mask(&self, mask: u64) -> Result {
        // SAFETY: By the type invariant of `device::Device`, `self.as_ref().as_raw()` is valid.
        to_result(unsafe { bindings::dma_set_mask(self.as_ref().as_raw(), mask) })
    }
}

    /// Performs the same functionality as [`CoherentAllocation::alloc_attrs`], except the
    /// `dma_attrs` is 0 by default.
    pub fn alloc_coherent<D: Device>(
        dev: &D,
        count: usize,
        gfp_flags: kernel::alloc::Flags,
    ) -> Result<CoherentAllocation<T>> {
        CoherentAllocation::alloc_attrs(dev, count, gfp_flags, Attrs(0))
    }

samples/rust/rust_dma.rs

    fn probe(pdev: Probing<&pci::Device<Core>>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
        dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");
        
        pdev.set_dma_mask(...);
        
        let pdev = pdev.into();

        let ca: CoherentAllocation<MyStruct> =
            CoherentAllocation::alloc_coherent(pdev, TEST_VALUES.len(), GFP_KERNEL)?;
        
        [...]
    }

### API Naming guidelines for conversion functions

Need input for method naming: https://lore.kernel.org/all/[e-mail]

This signature results in suboptimal code generation when `as_nanos` is not inlined:

pub trait HrTimerExpires {
    fn as_nanos(&self) -> i64;
}

Clippy complains if the `HrTimerExpires` is not `Copy` with the following signature:

pub trait HrTimerExpires {
    fn as_nanos(self) -> i64;
}

From the [upstream Rust API naming guidelines](https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv):

Conversions should be provided as methods, with names prefixed as follows:

| Prefix | Cost | Ownership |
| ------ | ---- | --------- |
| `as_` | Free | borrowed -\> borrowed |
| `to_` | Expensive | borrowed -\> borrowed<br>borrowed -\> owned (non-Copy types)<br>owned -\> owned (Copy types) |
| `into_` | Variable | owned -\> owned (non-Copy types) |

No guide line fits, what should be RfL recommendation for this situation?

Discussion dead end [here](https://lore.kernel.org/lkml/[e-mail]/) and [here](https://lore.kernel.org/lkml/[e-mail]/).

Alice:

pub trait HrTimerExpires: Copy {
    fn as_nanos(self) -> i64;
}

^ Benno & Gary like this solution
Andreas will add this resolution to reviewers guidelines.

### Guidelines for (racy) reads outside Rust AM (moved to next meeting)

Reading data such that the reads may be racy comes up again and again.

* Reading data from user space
* Reading from DMA buffers
* Reading hardware registers

Issue discussed here:

* [iov_iter](https://lore.kernel.org/all/[e-mail])
* [dma](https://lore.kernel.org/all/[e-mail])
* [block io](https://lore.kernel.org/all/[e-mail])

Besides the reads being racy, how do we inform the rust AM that it should consider data form these reads as initialized?

## Miscellaneous
<!-- stuff that does not fit into other categories -->

#### Xiang reports
##### `(p)init`

We have
- [ ] [#143553](https://github.com/rust-lang/rust/pull/143553) in early preview
- [x] HIR type-checking and type inference is working on the `init # [0]` smoke test
- [x] `init <literal>`
- [ ] It just ICEs because THIR is unimplemented, sorry
- [ ] Next PR
- [ ] :construction: THIR lowering (4x)
- [ ] :construction: MIR lowering and drop elaboration (5x), and pray that borrowck just works
- [ ] :construction: MIR instance paperwork (1x)
- [ ] Next PR
- [ ] :construction: `(val, val, ..)` parser support and HIR typeck (should be fast, 2x)
- [ ] :construction: the parser support for `struct` syntax
- [ ] :warning: polish it for nightly testing

##### `arbitrary_self_type`

We have
- [#143527](https://github.com/rust-lang/rust/pull/143527) also in early preview
- [x] Name resolution for identifiers
- Just enough for `Deref`/`Receiver` migration
- [x] Reserve a trait item attribute so that we mark traits eligible for supertrait item processing
- [ ] :construction: teach HIR trait coherence checks to correctly correct supertrait items
- [ ] :construction: RFC to receive official tracking issue nr.
- [ ] :warning: polish up for merge
- === RfL scope ends here ===
- [ ] :traffic_light: Next PR
- [ ] Migrate `Deref::Target` and apply the forementioned trait attribute
- [ ] Migrate all uses `deref_target` language item to `receiver_target`
- [ ] Crater run