netdev - Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

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] [day] [month] [year] [list]

Message-ID: <1484807558.2406.85.camel@redhat.com>
Date:   Thu, 19 Jan 2017 01:32:38 -0500
From:   Doug Ledford <dledford@...hat.com>
To:     David Miller <davem@...emloft.net>, tom@...bertland.com
Cc:     saeedm@....mellanox.co.il, saeedm@...lanox.com,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org, leon@...nel.org
Subject: Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver
 directory layout

On Thu, 2017-01-19 at 00:38 -0500, David Miller wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Wed, 18 Jan 2017 21:22:53 -0800
> 
> > In principle I  agree, but as I previously wrote backporting this
> > driver is already a bear. We need to do something here as this is
> > quickly approaching being infeasible to backport. Even if we don't
> > restructure the directories I'd still like to see some effort
> towards
> > feature modularization and isolation.
> 
> There simply is a lot changing all the time, no restructuring is
> going
> to reduce that.  The driver simply gets a lot of churn.
> 
> Backporting such things through a bunch of file and/or directory
> renames is seriously nothing but asking for more punishment.
> 
> That's why I am against it.

So, I spent the better part of two years dealing with this after the
drivers/net/mellanox drivers/net/ethernet/mellanox rename, so I'll
chime in.  Especially since Tom's problem directly relates to the
issues I dealt with when trying to take the latest Mellanox driver and
shoe-horn it into a Red Hat kernel that didn't have the same net core
(I had to pick and choose which mlx patches to take in order to work
with our existing net core, and the files were renamed on top of that).

If you rename a file from place A to place B and keep the file the
same, then a git backport can be done using techniques such as git
cherry-pick with the --follow option enabled.  It's slow, but works.

But that's not what you've brought up.  You brought up continuing the
rename to go further and split code out into files based upon features.
 While git cherry-pick can follow renames mostly automatically, it can
not follow refactors.  If they move the tcflower stuff out to a file on
its own, and you then attempt to backport some fix that touches the
tcflower support in the new location while you have not taken the move
patch, you will find that git will be totally stymied.

What you have now is not perfect and you have to sort through commits
to get the right ones and skip the ones you can't support, but things
mostly apply except when context diffs break issues.  With the refactor
and separation you speak of, git will be totally unable to help and you
will have to manually edit patches to point at new files or hand edit
the files to apply the patches.

I understand the desire for order instead of chaos, but it really will
not help.  Bringing patches from the new order back to the old chaos
will be so much harder than just continuing as things are that you will
silently curse the change shortly after it is made.

-- 
Doug Ledford <dledford@...hat.com>
    GPG KeyID: B826A3330E572FDD

Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)