On Sun, 16 Mar 2025 at 14:20, Antonio Hickey <cont...@byte-forge.io> wrote: > > Replacing all occurrences of `addr_of!(place)` and `addr_of_mut!(place)` > with `&raw const place` and `&raw mut place` respectively. > > This will allow us to reduce macro complexity, and improve consistency > with existing reference syntax as `&raw const`, `&raw mut` are similar > to `&`, `&mut` making it fit more naturally with other existing code. > > Suggested-by: Benno Lossin <benno.los...@proton.me> > Link: https://github.com/Rust-for-Linux/linux/issues/1148 > Signed-off-by: Antonio Hickey <cont...@antoniohickey.com> > ---
Thanks, Antonio. So this looks fine, but it's also a bit annoying, as the remaining KUnit/Rust integration patches[1] were recently updated to use `addr_of_mut!()`, so either this patch, or those, will need updating. In general, I think changes such as those in this series are going to get progressively more prone to conflicts as Rust is adopted by other subsystems, as the 'rust' tree won't be the only one carrying changes which could be affected. Maybe in the future it'd make sense to split these up into a series which enables the new feature, and only then put the warnings in place in the next version? In the KUnit case in particular, since the patches haven't actually been merged yet, we have three options: - Merge this into rust-next, and send out a new version of the KUnit patches which depend on it, which then are also carried in rust-next, or delayed (again) to 6.16. I suspect given how close to the merge window we are, the delay is more likely. - Merge the KUnit changes as-is (either into rust-next or kselftest/kunit), and send out a new version of this series which also updates it (probably in 6.16, but maybe sooner if everything goes via rust-next). - Merge both, and accept that there'll be some clippy errors until a follow-up patch fixing them is sent and merged. As someone with a vested interest in the KUnit changes, and at best a mild academic interest in the addr_of_muit!() deprecation, my preferences are with the latter two options. (I'd also, in general, whinge that the frequency of new Rust versions / warnings is high enough that it's taking a not insignificant portion of the limited time I have working on Rust things to understand and deal with the churn.) Regardless, apart from the minor irritation of having to learn yet another new syntax, I have no objections to this patch in particular. Reviewed-by: David Gow <david...@google.com> Thanks (and sorry for the grumpiness: don't take it personally), -- David [1]: https://lore.kernel.org/rust-for-linux/20250307090103.918788-1-david...@google.com/
smime.p7s
Description: S/MIME Cryptographic Signature
