[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8cfe2c0-751b-4fbd-9819-b6fdb6dde724@lunn.ch>
Date: Thu, 13 Jun 2024 15:20:25 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
netdev-driver-reviewers@...r.kernel.org
Subject: Re: [ANN] netdev call - May 7th
On Thu, Jun 13, 2024 at 02:11:11PM +0200, Przemek Kitszel wrote:
> On 5/7/24 16:05, Andrew Lunn wrote:
> > On Mon, May 06, 2024 at 07:52:57AM -0700, Jakub Kicinski wrote:
> > > Hi!
> > >
> > > The bi-weekly call is scheduled for tomorrow at 8:30 am (PT) /
> > > 5:30 pm (~EU). Last call before the merge window. No agenda
> > > items have been submitted so far.
> > >
> > > See you at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> >
> > Maybe we can have a quick discussion and poll about:
> >
> > https://patchwork.kernel.org/project/netdevbpf/patch/20240507090520.284821-1-wei.fang@nxp.com/
> >
> > Do we want patches like this? What do people think about guard() vs
> > scoped_guard().
> >
> > Andrew
> >
> Was it discussed? Any conclusions?
Sorry, i should of submitted a netdev FAQ Documentation patch by now.
The summary is: scoped_guard() is O.K. for new code. guard() is too
magical, and should not be used. Neither should be used in old code,
where we perceive a danger it will actually cause more bugs when back
porting fixes.
We do acknowledge these mechanisms could be useful at avoiding bugs,
but want to wait and see how they work out in practice. It could be
the restrictions on reworking old code is lifted, and guard() allowed,
in a few years.
Andrew
Powered by blists - more mailing lists