[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PAXPR04MB85100FF5080EA3C8E093C39988E22@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 13 May 2024 01:21:52 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>, Shenwei Wang <shenwei.wang@....com>,
Clark Wang <xiaoning.wang@....com>, "richardcochran@...il.com"
<richardcochran@...il.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: RE: [PATCH v2 net-next] net: fec: Convert fec driver to use lock
guards
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: 2024年5月11日 22:30
> To: Wei Fang <wei.fang@....com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; Shenwei Wang <shenwei.wang@....com>; Clark Wang
> <xiaoning.wang@....com>; richardcochran@...il.com;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; imx@...ts.linux.dev
> Subject: Re: [PATCH v2 net-next] net: fec: Convert fec driver to use lock guards
>
> On Sat, May 11, 2024 at 11:02:29AM +0800, Wei Fang wrote:
> > The Scope-based resource management mechanism has been introduced
> into
> > kernel since the commit 54da6a092431 ("locking: Introduce __cleanup()
> > based infrastructure"). The mechanism leverages the 'cleanup'
> > attribute provided by GCC and Clang, which allows resources to be
> > automatically released when they go out of scope.
> > Therefore, convert the fec driver to use guard() and scoped_guard()
> > defined in linux/cleanup.h to automate lock lifetime control in the
> > fec driver.
>
> Sorry, it has been decided for netdev we don't want these sort of conversions,
> at least not yet. The main worry is backporting fixes. It is likely such bcakports
> are going to be harder, and also more error prone, since the context is quite
> different.
>
> If done correctly, scoped_guard() {} could be useful, and avoid issues. So we are
> O.K. with that in new code. That will also allow us to get some experience with
> it over the next few years. Maybe we will then re-evaluate this decision about
> converting existing code.
>
Okay, it's fine, thanks.
>
Powered by blists - more mailing lists