[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220906161848.sbmz6x7xsfdgdx3g@skbuf>
Date: Tue, 6 Sep 2022 16:18:49 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Colin Foster <colin.foster@...advantage.com>
CC: Christian Marangi <ansuelsmth@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vladimir Oltean <olteanv@...il.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <razor@...ckwall.org>,
Tobias Waldekranz <tobias@...dekranz.com>,
Marek Behún <kabel@...nel.org>,
DENG Qingfang <dqfext@...il.com>,
Alvin Šipraga <alsi@...g-olufsen.dk>,
Linus Walleij <linus.walleij@...aro.org>,
Luiz Angelo Daros de Luca <luizluca@...il.com>,
Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
Sean Wang <sean.wang@...iatek.com>
Subject: Re: [PATCH net-next 0/9] DSA changes for multiple CPU ports (part 4)
On Tue, Sep 06, 2022 at 09:10:43AM -0700, Colin Foster wrote:
> On Sun, Sep 04, 2022 at 07:34:14PM +0000, Vladimir Oltean wrote:
> > On Fri, Sep 02, 2022 at 08:44:37PM +0200, Christian Marangi wrote:
> > For transparency, here is the commit list I used to produce the backport (top-most is most recent):
>
> Tangentially related: how did you come up with this list?
>
> I can only assume this is a manual process based on intricate knowledge
> of net / DSA as a whole. I just want to make sure there isn't a "git
> backport net/dsa origin/master v5.10" sort of thing ;-)
Years of practice ;)
Although I found a tool called git-deps and I ran it in a few places,
I found it to be fundamentally lacking for correct kernel backporting
work. The way that tool works is it finds patches related to the current
one based on what other lines from this patch's context they touch.
This obviously isn't going to work too well. There may very well be no
connection obvious to this tool between, say, a function prototype added
to include/net/dsa.h and its first use in drivers/net/dsa/mv88e6xxx/chip.c.
So it may not know it has to backport the include/net/dsa.h change.
I suspect one way in which git-deps may be modified in order to be much
more useful for kernel work is for it to backport the entire patch
series from which the dependency commit came. But (1) I don't know
python even enough to be able to manage a pip virtual environment, let
alone code up such a change, and (2) I'm not sure, from a kernel devel
process perspective, that we offer enough machine-parsable hints such
that a python program can just figure out "yes, these are the patches
that all belong to the same patch set as commit X".
Powered by blists - more mailing lists