John Hubbard
2025-Dec-01 22:17 UTC
[PATCH v3] rust: clist: Add support to interface with C linked lists
On 12/1/25 12:32 PM, Joel Fernandes wrote:> On 11/30/2025 7:34 PM, John Hubbard wrote: >> On 11/29/25 1:30 PM, Joel Fernandes wrote:...>> This is sufficiently tricky that I think it needs some code to exercise it. >> >> Lately I'm not sure what to recommend, there are several choices, each with >> trade-offs: kunit, samples/rust, or even new DRM Rust code. Maybe the last >> one is especially nice, because it doesn't really have many downsides. >> >> Rather than wait for any of that, I wrote a quick samples/rust/rust_clist.rs >> and used it to sanity check my review findings, which are below. > > In v1, I had a samples/rust/ patch, but everyone's opinion almost unanimously > was this does not belong in a sample, but rather in doctests. What in the sample > is not supported by the current doctest? If something is missing, I think I can > add it in. Plus yes, DRM_BUDDY is going to be a consumer shortly.Well, I won't contest the choice of doctests, since wiser heads than mine have already worked through the tradeoffs. But for API developers, the problem with doctests is that no one has ever actually *run* the code. It's just a build test. And so critical bugs, such as the kernel crash/hang below, are missed. I would humbly suggest that you build and *run* your own samples code, for new code that has no users yet. Because if you are skipping steps like this (posting the code before there is an actual caller), then the documentation of how to use it is not "just documentation" anymore--it really needs to run correctly. And actually, after writing the above...I still think it would be better to post this with its first caller (DRM_BUDDY, or BUDDY_DRM_ALUMNI, or however it ends up), so that we can see how it looks and behaves in practice. What's the rush? ...>> The fix requires two-step initialization, like this, for example: > > It has nothing to do with 2-step initialization. The issue is only related to > the HEAD (and not the items) right? The issue is `assume_init()` should not be > used on self-referential structures, the fix just one line: > > -//! # unsafe { init_list_head(head.as_mut_ptr()) }; > -//! # let mut head = unsafe { head.assume_init() }; > > +//! # let head = head.as_mut_ptr(); > +//! # unsafe { init_list_head(head) }; > > Does that fix the issue in your private sample test too? > > Or did I miss what you're suggesting? >Yes, you are correct: the main point is to avoid moving a struct that contains self-referential fields. So your version is a more accurate and better fix. ...>>> +pub struct Clist<'a, T> { >>> + head: &'a ClistHead, >>> + offset: usize, >>> + _phantom: PhantomData<&'a T>, >>> +} >> >> This discards build-time (const generic) information, and demotes it to >> runtime (.offset), without any real benefit. I believe it's better to keep >> it as a const generic, like this: >> >> pub struct Clist<'a, T, const OFFSET: usize> { >> head: &'a ClistHead, >> _phantom: PhantomData<&'a T>, >> } >> >>> + >>> +impl<'a, T> Clist<'a, T> { >> >> And here, the above becomes: >> >> impl<'a, T, const OFFSET: usize> Clist<'a, T, OFFSET> { >> >> ...etc. > > It is not ignored, the const-generic part only applies to the constructor method > in my patch. I didn't want to add another argument to the diamond brackets, the > type name looks really ugly then. >The macro hides it, though. Users never have to write the full type. Increasing const-ness is worth something. The messy syntax is unfortunate, but I don't really know what to say there.> The only advantage I think of doing this (inspite of the obvious aesthetic > disadvantage) is that a mutable `Clist` cannot have its offset modified. Let me > see if I can get Alice's suggestion to make it a const in the struct work to > solve that.Yes. I have it working locally, so I'm confident that you will prevail. :) thanks, -- John Hubbard
Joel Fernandes
2025-Dec-01 22:43 UTC
[PATCH v3] rust: clist: Add support to interface with C linked lists
On 12/1/2025 5:17 PM, John Hubbard wrote:> On 12/1/25 12:32 PM, Joel Fernandes wrote: >> On 11/30/2025 7:34 PM, John Hubbard wrote: >>> On 11/29/25 1:30 PM, Joel Fernandes wrote: > ... >>> This is sufficiently tricky that I think it needs some code to exercise it. >>> >>> Lately I'm not sure what to recommend, there are several choices, each with >>> trade-offs: kunit, samples/rust, or even new DRM Rust code. Maybe the last >>> one is especially nice, because it doesn't really have many downsides. >>> >>> Rather than wait for any of that, I wrote a quick samples/rust/rust_clist.rs >>> and used it to sanity check my review findings, which are below. >> >> In v1, I had a samples/rust/ patch, but everyone's opinion almost unanimously >> was this does not belong in a sample, but rather in doctests. What in the sample >> is not supported by the current doctest? If something is missing, I think I can >> add it in. Plus yes, DRM_BUDDY is going to be a consumer shortly. > > Well, I won't contest the choice of doctests, since wiser heads than mine > have already worked through the tradeoffs. > > But for API developers, the problem with doctests is that no one has ever > actually *run* the code. It's just a build test. And so critical bugs, such > as the kernel crash/hang below, are missed.You may want to read [1]. CONFIG_RUST_KERNEL_DOCTESTS are run at runtime. You enable it and boot the kernel. The documentation clearly says "doctests get compiled as Rust kernel objects, allowing them to run against a built kernel.". And this is how I have run it as well. [1] https://docs.kernel.org/rust/testing.html This also explains why you think list_add_tail() is a noop in my patch, which it is not.> > I would humbly suggest that you build and *run* your own samples code, for > new code that has no users yet.Yes, I already have an internal tree running it. :) I am not sure why the assume_init() triggered for you but not for me, I don't think has anything to do with doctests since the doctests is in fact just rust code compiled as KUNIT tests.> Because if you are skipping steps like this (posting the code before > there is an actual caller), then the documentation of how to use it > is not "just documentation" anymore--it really needs to run correctly.No, that's the thing, these are run. You really are in the wrong here and appear to not understand how doctests work.> And actually, after writing the above...I still think it would be better > to post this with its first caller (DRM_BUDDY, or BUDDY_DRM_ALUMNI, or > however it ends up), so that we can see how it looks and behaves in > practice. > > What's the rush?Who said anything about a rush? I am really confused by what you mean. It is useful to post patches even if there are external dependencies to get feedback. So this is also an invalid review comment unfortunately. There is no rush, this is v3 now, did you miss that? Thanks.