[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y3KBfLLyQZ7Q95bG@smile.fi.intel.com>
Date: Mon, 14 Nov 2022 19:57:16 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: kernel test robot <lkp@...el.com>,
Jakob Koschel <jakobkoschel@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mathias Nyman <mathias.nyman@...ux.intel.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
oe-kbuild-all@...ts.linux.dev, Kevin Cernekee <cernekee@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [PATCH v1 1/4] list: Introduce list_count() to count existing
nodes
On Mon, Nov 14, 2022 at 05:47:21PM +0000, Matthew Wilcox wrote:
> On Mon, Nov 14, 2022 at 06:03:00PM +0200, Andy Shevchenko wrote:
> > Oh, nice! I will fix this for v2.
>
> list_count() is an antipattern. I don't have any of the patches in
> my inbox, so maybe there's a great reason for doing this, but my
> immediate response is: NAK.
When we are trying to hide iterator variable in many cases, leaving the current
code alive will allow explicit access to it. If it's not a problem, why to
bother with the other list APIs then?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists