On 6/11/26 10:29, Andy Shevchenko wrote: > On Thu, Jun 11, 2026 at 10:01:25AM +0200, Christian König wrote: >> On 6/10/26 17:02, Andy Shevchenko wrote: >>> On Wed, Jun 10, 2026 at 11:11:34AM +0200, Christian König wrote: >>>> On 6/10/26 10:18, Kaitao Cheng wrote: >>>>> 在 2026/6/10 16:07, Christian König 写道: > > ... > >>>>> Should we revert to v1, or keep list_for_each_entry() and >>>>> list_for_each_entry_safe() as they are, close this thread, and make no >>>>> changes? >>>>> >>>>> Link to v1: >>>>> https://lore.kernel.org/all/[email protected]/ >>>>> >>>>> Or do you have any better suggestions? >>>> >>>> v1 looks perfectly reasonable to me. >>> >>> But why not just hiding that once for all (in case they don't use the >>> temporary >>> iterator)? Easy to automate, robust — everyone is happy? >> >> As far as I can see that is an extremely bad idea. >> >> The distinction between the use cases of 'iterating the list' and 'iterating >> the list while you modify it' is completely intentional. > > What I meant is to keep the name, just drop the parameter (make it hidden and > being defined inside list_for_each_*_safe() cases).
Ah, sorry I was still thinking the suggestion is to merge list_for_each_entry() and list_for_each_entry_safe(). If the modification is done all at once or in steps doesn't really matter for me as long as the patch can be re-created reproducible. But I'm wondering if we couldn't improve the name at the same time. The _safe() postfix has caused tons of confusion where especially beginners thought that it is a thread-safe variant, which it clearly isn't. The _mutable() postfix sounds like a much better description to what happens here. Regards, Christian. > >> See the bool type can be implemented by int as well, but it is just a >> different use case. > >>>> You should just include some patches in the same patch set to actually use >>>> the new macros. >>>> >>>> If you modify the files under drivers/dma-buf or drivers/gpu/drm/amd to use >>>> the new macro I'm happy to review that. >>> >> >
