[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20251113140620.bc768aa94d734a654c31857c@linux-foundation.org>
Date: Thu, 13 Nov 2025 14:06:20 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Ming Lei <ming.lei@...hat.com>
Cc: Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org, Caleb Sander
Mateos <csander@...estorage.com>, Uday Shankar <ushankar@...estorage.com>,
Stefani Seibold <stefani@...bold.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 01/27] kfifo: add kfifo_alloc_node() helper for NUMA
awareness
On Thu, 13 Nov 2025 09:21:41 +0800 Ming Lei <ming.lei@...hat.com> wrote:
> > > +#define kfifo_alloc_node(fifo, size, gfp_mask, node) \
> > > +__kfifo_int_must_check_helper( \
> > > +({ \
> > > + typeof((fifo) + 1) __tmp = (fifo); \
> > > + struct __kfifo *__kfifo = &__tmp->kfifo; \
> > > + __is_kfifo_ptr(__tmp) ? \
> > > + __kfifo_alloc_node(__kfifo, size, sizeof(*__tmp->type), gfp_mask, node) : \
> > > + -EINVAL; \
> > > +}) \
> > > +)
> >
> > Well this is an eyesore. Do we really need it? It seems to be here so
> > we can check for a programming bug? Well, don't add programming bugs!
> >
> > I'm actually not enjoying the existence of __is_kfifo_ptr() at all.
> > What is it all doing? It's a FIFO for heck's sake, why is this so hard.
>
> It is basically a clone of existing kfifo_alloc().
>
> Do we need to clean kfifo_alloc() first? Otherwise I'd keep the same
> pattern with existing definitions.
Is OK, I was just whining. Possibly de-over-engineering kifo is a
separate project.
Powered by blists - more mailing lists