rust/kernel/lib.rs | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
It doesn't make sense to allow multiple fields to be specified in
offset_of.
No functional change.
Signed-off-by: Wei Liu <wei.liu@kernel.org>
---
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: Björn Roy Baron <bjorn3_gh@protonmail.com>
---
rust/kernel/lib.rs | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 6a322effa60c..2f3601e4e27e 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -208,7 +208,7 @@ impl<'a> Drop for KParamGuard<'a> {
/// ```
#[macro_export]
macro_rules! offset_of {
- ($type:ty, $($f:tt)*) => {{
+ ($type:ty, $f:tt) => {{
let tmp = core::mem::MaybeUninit::<$type>::uninit();
let outer = tmp.as_ptr();
// To avoid warnings when nesting `unsafe` blocks.
@@ -216,12 +216,14 @@ macro_rules! offset_of {
// SAFETY: The pointer is valid and aligned, just not initialised; `addr_of` ensures that
// we don't actually read from `outer` (which would be UB) nor create an intermediate
// reference.
- let inner = unsafe { core::ptr::addr_of!((*outer).$($f)*) } as *const u8;
+ let inner = unsafe { core::ptr::addr_of!((*outer).$f) } as *const u8;
// To avoid warnings when nesting `unsafe` blocks.
#[allow(unused_unsafe)]
// SAFETY: The two pointers are within the same allocation block.
- unsafe { inner.offset_from(outer as *const u8) }
- }}
+ unsafe {
+ inner.offset_from(outer as *const u8)
+ }
+ }};
}
/// Produces a pointer to an object from a pointer to one of its fields.
--
2.35.1
On Fri, 16 Dec 2022 at 17:49, Wei Liu <wei.liu@kernel.org> wrote: > > It doesn't make sense to allow multiple fields to be specified in > offset_of. Why do you say it doesn't make sense? Here's what I had in mind: ``` struct Y { z: u32 } struct X { y: Y } offset_of!(X, y.z) ``` Which is something very plausible. > No functional change. > > Signed-off-by: Wei Liu <wei.liu@kernel.org> > --- > Cc: Miguel Ojeda <ojeda@kernel.org> > Cc: Alex Gaynor <alex.gaynor@gmail.com> > Cc: Wedson Almeida Filho <wedsonaf@gmail.com> > Cc: Boqun Feng <boqun.feng@gmail.com> > Cc: Gary Guo <gary@garyguo.net> > Cc: Björn Roy Baron <bjorn3_gh@protonmail.com> > --- > rust/kernel/lib.rs | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs > index 6a322effa60c..2f3601e4e27e 100644 > --- a/rust/kernel/lib.rs > +++ b/rust/kernel/lib.rs > @@ -208,7 +208,7 @@ impl<'a> Drop for KParamGuard<'a> { > /// ``` > #[macro_export] > macro_rules! offset_of { > - ($type:ty, $($f:tt)*) => {{ > + ($type:ty, $f:tt) => {{ > let tmp = core::mem::MaybeUninit::<$type>::uninit(); > let outer = tmp.as_ptr(); > // To avoid warnings when nesting `unsafe` blocks. > @@ -216,12 +216,14 @@ macro_rules! offset_of { > // SAFETY: The pointer is valid and aligned, just not initialised; `addr_of` ensures that > // we don't actually read from `outer` (which would be UB) nor create an intermediate > // reference. > - let inner = unsafe { core::ptr::addr_of!((*outer).$($f)*) } as *const u8; > + let inner = unsafe { core::ptr::addr_of!((*outer).$f) } as *const u8; > // To avoid warnings when nesting `unsafe` blocks. > #[allow(unused_unsafe)] > // SAFETY: The two pointers are within the same allocation block. > - unsafe { inner.offset_from(outer as *const u8) } > - }} > + unsafe { > + inner.offset_from(outer as *const u8) > + } > + }}; > } > > /// Produces a pointer to an object from a pointer to one of its fields. > -- > 2.35.1 >
On Fri, Dec 16, 2022 at 06:26:57PM +0000, Wedson Almeida Filho wrote: > On Fri, 16 Dec 2022 at 17:49, Wei Liu <wei.liu@kernel.org> wrote: > > > > It doesn't make sense to allow multiple fields to be specified in > > offset_of. > > Why do you say it doesn't make sense? > > Here's what I had in mind: > ``` > struct Y { > z: u32 > } > struct X { > y: Y > } > offset_of!(X, y.z) > ``` > > Which is something very plausible. > > > No functional change. > > > > Signed-off-by: Wei Liu <wei.liu@kernel.org> > > --- > > Cc: Miguel Ojeda <ojeda@kernel.org> > > Cc: Alex Gaynor <alex.gaynor@gmail.com> > > Cc: Wedson Almeida Filho <wedsonaf@gmail.com> > > Cc: Boqun Feng <boqun.feng@gmail.com> > > Cc: Gary Guo <gary@garyguo.net> > > Cc: Björn Roy Baron <bjorn3_gh@protonmail.com> > > --- > > rust/kernel/lib.rs | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs > > index 6a322effa60c..2f3601e4e27e 100644 > > --- a/rust/kernel/lib.rs > > +++ b/rust/kernel/lib.rs > > @@ -208,7 +208,7 @@ impl<'a> Drop for KParamGuard<'a> { > > /// ``` > > #[macro_export] > > macro_rules! offset_of { > > - ($type:ty, $($f:tt)*) => {{ Shouldn't this be + instead of *? offset_of!(X,) is valid according to this pattern. Thanks, Wei.
On Fri, Dec 16, 2022 at 06:26:57PM +0000, Wedson Almeida Filho wrote: > On Fri, 16 Dec 2022 at 17:49, Wei Liu <wei.liu@kernel.org> wrote: > > > > It doesn't make sense to allow multiple fields to be specified in > > offset_of. > > Why do you say it doesn't make sense? > > Here's what I had in mind: > ``` > struct Y { > z: u32 > } > struct X { > y: Y > } > offset_of!(X, y.z) > ``` > > Which is something very plausible. You're right. I didn't consider that use case. This patch can be ignored. Thanks, Wei.
On Fri, Dec 16, 2022 at 06:26:57PM +0000, Wedson Almeida Filho wrote: > On Fri, 16 Dec 2022 at 17:49, Wei Liu <wei.liu@kernel.org> wrote: > > > > It doesn't make sense to allow multiple fields to be specified in > > offset_of. > > Why do you say it doesn't make sense? > > Here's what I had in mind: > ``` > struct Y { > z: u32 > } > struct X { > y: Y > } > offset_of!(X, y.z) For me, it's not very obvious that "y.z" is multiples of token trees rather a single token tree ;-) Maybe some examples of the match pattern of macros can help people catch up faster? Like "y.z" => tt [y], tt [.], tt [z] I will defer to Gary or Bjorn for a better quick guide of Rust macros ;-) Regards, Boqun > ``` > > Which is something very plausible. > > > No functional change. > > > > Signed-off-by: Wei Liu <wei.liu@kernel.org> > > --- > > Cc: Miguel Ojeda <ojeda@kernel.org> > > Cc: Alex Gaynor <alex.gaynor@gmail.com> > > Cc: Wedson Almeida Filho <wedsonaf@gmail.com> > > Cc: Boqun Feng <boqun.feng@gmail.com> > > Cc: Gary Guo <gary@garyguo.net> > > Cc: Björn Roy Baron <bjorn3_gh@protonmail.com> > > --- > > rust/kernel/lib.rs | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs > > index 6a322effa60c..2f3601e4e27e 100644 > > --- a/rust/kernel/lib.rs > > +++ b/rust/kernel/lib.rs > > @@ -208,7 +208,7 @@ impl<'a> Drop for KParamGuard<'a> { > > /// ``` > > #[macro_export] > > macro_rules! offset_of { > > - ($type:ty, $($f:tt)*) => {{ > > + ($type:ty, $f:tt) => {{ > > let tmp = core::mem::MaybeUninit::<$type>::uninit(); > > let outer = tmp.as_ptr(); > > // To avoid warnings when nesting `unsafe` blocks. > > @@ -216,12 +216,14 @@ macro_rules! offset_of { > > // SAFETY: The pointer is valid and aligned, just not initialised; `addr_of` ensures that > > // we don't actually read from `outer` (which would be UB) nor create an intermediate > > // reference. > > - let inner = unsafe { core::ptr::addr_of!((*outer).$($f)*) } as *const u8; > > + let inner = unsafe { core::ptr::addr_of!((*outer).$f) } as *const u8; > > // To avoid warnings when nesting `unsafe` blocks. > > #[allow(unused_unsafe)] > > // SAFETY: The two pointers are within the same allocation block. > > - unsafe { inner.offset_from(outer as *const u8) } > > - }} > > + unsafe { > > + inner.offset_from(outer as *const u8) > > + } > > + }}; > > } > > > > /// Produces a pointer to an object from a pointer to one of its fields. > > -- > > 2.35.1 > >
On Fri, Dec 16, 2022 at 02:15:16PM -0800, Boqun Feng wrote: > On Fri, Dec 16, 2022 at 06:26:57PM +0000, Wedson Almeida Filho wrote: > > On Fri, 16 Dec 2022 at 17:49, Wei Liu <wei.liu@kernel.org> wrote: > > > > > > It doesn't make sense to allow multiple fields to be specified in > > > offset_of. > > > > Why do you say it doesn't make sense? > > > > Here's what I had in mind: > > ``` > > struct Y { > > z: u32 > > } > > struct X { > > y: Y > > } > > offset_of!(X, y.z) > > For me, it's not very obvious that "y.z" is multiples of token trees > rather a single token tree ;-) > > Maybe some examples of the match pattern of macros can help people catch > up faster? Like > > "y.z" => tt [y], tt [.], tt [z] > > I will defer to Gary or Bjorn for a better quick guide of Rust macros > ;-) > What will be even better is someone please contribute such a macro to libcore so that I don't have to replicate the code snippet everywhere. :-) I have a version somewhere, the second argument matches against ident, which was definitely not as flexible as tt. Thanks, Wei.
On Sat, Dec 17, 2022 at 12:30 AM Wei Liu <wei.liu@kernel.org> wrote: > > What will be even better is someone please contribute such a macro to > libcore so that I don't have to replicate the code snippet everywhere. > :-) It is happening! :-) See https://github.com/rust-lang/rfcs/pull/3308, currently at the end of the FCP ("final comment period"), i.e. the RFC is likely getting accepted soon. We track it at https://github.com/Rust-for-Linux/linux/issues/514 (one of the sub-lists in issue #2). Cheers, Miguel
© 2016 - 2025 Red Hat, Inc.