netdev - Re: [PATCH net-next 00/17] Remove dsa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Nov 2022 11:16:07 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 00/17] Remove dsa_priv.h

On 11/21/22 05:55, Vladimir Oltean wrote:
> After working on the "Autoload DSA tagging driver when dynamically
> changing protocol" series:
> https://patchwork.kernel.org/project/netdevbpf/cover/20221115011847.2843127-1-vladimir.oltean@nxp.com/
> 
> it became clear to me that the situation with DSA headers is a bit
> messy, and I put the tagging protocol driver macros in a pretty random
> temporary spot in dsa_priv.h.
> 
> Now is the time to make the net/dsa/ folder a bit more organized, and to
> make tagging protocol driver modules include just headers they're going
> to use.
> 
> Another thing is the merging and cleanup of dsa.c and dsa2.c. Before,
> dsa.c had 589 lines and dsa2.c had 1817 lines. Now, the combined dsa.c
> has 1749 lines, the rest went to some other places.
> 
> Sorry for the set size, I know the rules, but since this is basically
> code movement for the most part, I thought more patches are better.

This all looks fine on paper, only concern is that it will make our 
lives so much more miserable for back porting fixes into older kernels, 
if you are fine with that as a co-maintainer, then so am I.

That argument could always be used to make zero re-structuring and it 
would be sad for DSA to ossify, so obviously should not be the major 
reason for not making changes.

Thanks for doing this work!
-- 
Florian