Signed-off-by: mu001999 <[email protected]>
---
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
On Wed, May 22, 2024 at 2:27 PM mu001999 <[email protected]> wrote:
>
> Signed-off-by: mu001999 <[email protected]>
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
On Wed, May 22, 2024 at 2:27 PM mu001999 <[email protected]> wrote:
>
> Signed-off-by: mu001999 <[email protected]>
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
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 <[email protected]>
发送时间: 2024年5月22日 20:38
收件人: mu001999
抄送: [email protected]; [email protected]; [email protected]; [email protected]
主题: Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics
On Wed, May 22, 2024 at 2:27 PM mu001999 <[email protected]> wrote:
>
> Signed-off-by: mu001999 <[email protected]>
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
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 <[email protected]>
发送时间: 2024年5月22日 20:37
收件人: mu001999
抄送: [email protected]; [email protected]; [email protected]; [email protected]
主题: Re: [PATCH] rust: kernel: make impl_has_work compatible with more complex generics
On Wed, May 22, 2024 at 2:27 PM mu001999 <[email protected]> wrote:
>
> Signed-off-by: mu001999 <[email protected]>
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
On 22.05.24 14:37, Alice Ryhl wrote:
> On Wed, May 22, 2024 at 2:27 PM mu001999 <[email protected]> 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