[PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[mu001999]

Signed-off-by: mu001999 <mu001999@outlook.com>
---
 rust/kernel/workqueue.rs | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 1cec63a2aea8..1ff81d88b61d 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -482,24 +482,25 @@ unsafe fn work_container_of(ptr: *mut Work<T, ID>) -> *mut Self
 /// use kernel::sync::Arc;
 /// use kernel::workqueue::{self, impl_has_work, Work};
 ///
-/// struct MyStruct {
-///     work_field: Work<MyStruct, 17>,
+/// struct MyStruct<'a, T, const N: usize> {
+///     work_field: Work<MyStruct<'a, T, N>, 17>,
+///     f: fn(&'a [T; N]),
 /// }
 ///
 /// impl_has_work! {
-///     impl HasWork<MyStruct, 17> for MyStruct { self.work_field }
+///     impl{'a, T, const N: usize} HasWork<MyStruct<'a, T, N>, 17> for MyStruct<'a, T, N> { self.work_field }
 /// }
 /// ```
 #[macro_export]
 macro_rules! impl_has_work {
-    ($(impl$(<$($implarg:ident),*>)?
+    ($(impl$({$($generics:tt)*})?
        HasWork<$work_type:ty $(, $id:tt)?>
-       for $self:ident $(<$($selfarg:ident),*>)?
+       for $self:ty
        { self.$field:ident }
     )*) => {$(
         // SAFETY: The implementation of `raw_get_work` only compiles if the field has the right
         // type.
-        unsafe impl$(<$($implarg),*>)? $crate::workqueue::HasWork<$work_type $(, $id)?> for $self $(<$($selfarg),*>)? {
+        unsafe impl$(<$($generics)+>)? $crate::workqueue::HasWork<$work_type $(, $id)?> for $self {
             const OFFSET: usize = ::core::mem::offset_of!(Self, $field) as usize;
 
             #[inline]
@@ -515,7 +516,7 @@ unsafe fn raw_get_work(ptr: *mut Self) -> *mut $crate::workqueue::Work<$work_typ
 pub use impl_has_work;
 
 impl_has_work! {
-    impl<T> HasWork<Self> for ClosureWork<T> { self.work }
+    impl{T} HasWork<Self> for ClosureWork<T> { self.work }
 }
 
 unsafe impl<T, const ID: u64> WorkItemPointer<ID> for Arc<T>
-- 
2.34.1

Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[Alice Ryhl]

On Wed, May 22, 2024 at 2:27 PM mu001999 <mu001999@outlook.com> wrote:
>
> Signed-off-by: mu001999 <mu001999@outlook.com>

Please provide a more complete commit description. What user motivates
this change?

>  impl_has_work! {
> -    impl<T> HasWork<Self> for ClosureWork<T> { self.work }
> +    impl{T} HasWork<Self> for ClosureWork<T> { self.work }
>  }

I ended up doing something similar for the generics in some of the
linked list patches. Does anyone know if it's possible to support this
without giving up the <T> syntax?

Alice

Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[Miguel Ojeda]

On Wed, May 22, 2024 at 2:27 PM mu001999 <mu001999@outlook.com> wrote:
>
> Signed-off-by: mu001999 <mu001999@outlook.com>

The kernel requires a "known identity" (it does not accept anonymous
contributions) -- please see
https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin.

Cheers,
Miguel

回复: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[Xu Roland]

Miguel Ojeda Wrote:
> The kernel requires a "known identity" (it does not accept anonymous
> contributions)

Sorry, I sent another email and use the formal name.

________________________________________
发件人: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
发送时间: 2024年5月22日 20:38
收件人: mu001999
抄送: ojeda@kernel.org; boqun.feng@gmail.com; rust-for-linux@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

On Wed, May 22, 2024 at 2:27 PM mu001999 <mu001999@outlook.com> wrote:
>
> Signed-off-by: mu001999 <mu001999@outlook.com>

The kernel requires a "known identity" (it does not accept anonymous
contributions) -- please see
https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin.

Cheers,
Miguel

回复: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[Xu Roland]

Alice Ryhl Wrote:
> Please provide a more complete commit description. What user motivates
> this change?

I sent two new emails but I thought I made something wrong cause It seems not consequent with this.
And I found this issue at https://github.com/Rust-for-Linux/linux/issues/1077

________________________________________
发件人: Alice Ryhl <aliceryhl@google.com>
发送时间: 2024年5月22日 20:37
收件人: mu001999
抄送: ojeda@kernel.org; boqun.feng@gmail.com; rust-for-linux@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

On Wed, May 22, 2024 at 2:27 PM mu001999 <mu001999@outlook.com> wrote:
>
> Signed-off-by: mu001999 <mu001999@outlook.com>

Please provide a more complete commit description. What user motivates
this change?

>  impl_has_work! {
> -    impl<T> HasWork<Self> for ClosureWork<T> { self.work }
> +    impl{T} HasWork<Self> for ClosureWork<T> { self.work }
>  }

I ended up doing something similar for the generics in some of the
linked list patches. Does anyone know if it's possible to support this
without giving up the <T> syntax?

Alice

Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics

[Benno Lossin]

On 22.05.24 14:37, Alice Ryhl wrote:
> On Wed, May 22, 2024 at 2:27 PM mu001999 <mu001999@outlook.com> wrote:
>>  impl_has_work! {
>> -    impl<T> HasWork<Self> for ClosureWork<T> { self.work }
>> +    impl{T} HasWork<Self> for ClosureWork<T> { self.work }
>>  }
> 
> I ended up doing something similar for the generics in some of the
> linked list patches. Does anyone know if it's possible to support this
> without giving up the <T> syntax?

I tried to come up with something some time ago, but it was not really
nice. You have to parse the entire generics manually, which ends up
looking horrible. I have been thinking some time now that a `generics`
fragment would actually be really useful in declarative macros.

I also thought that if we get even more `Has*` traits for intrusive
datastructures, we could add a unified derive macro that allows you to
just do:

    #[derive(Intrusive)]
    struct MyStruct {
        #[intrusive]
        work: Work<Self>,
        #[intrusive]
        timer: Timer<Self>,
        /* ... */
    }

But I thought that as long as we have only two intrusive structures, we
don't need this.

---
Cheers,
Benno