lkml.org 
[lkml]   [2019]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC, Tree] De-clutter the top level directory, move ipc/ => kernel/ipc/, samples/ => Documentation/samples/ and sound/ => drivers/sound/

    * Greg KH <gregkh@linuxfoundation.org> wrote:

    > On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
    > >
    > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
    > >
    > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
    > > > <brendanhiggins@google.com> wrote:
    > > > >
    > > > > Sorry about that. I am surprised that none of the other reviewers
    > > > > brought this up.
    > > >
    > > > I think I'm "special".
    > > >
    > > > There was some other similar change a few years ago, which I
    > > > absolutely hated because of how it broke autocomplete for me. Very few
    > > > other people seemed to react to it.
    > >
    > > FWIW, I am obsessively sensitive to autocomplete and overall source code
    > > file hieararchy and nomenclature details as well, so it's not just you.
    > >
    > > Beyond the muscle memory aspect, nonsensical naming and inanely flat file
    > > hierarchies annoy kernel developers and makes it harder for newbies to
    > > understand the kernel source as well.
    > >
    > > The less clutter, the more organization, the better - and there's very
    > > few valid technical reasons to add any new files or directories to the
    > > top level directory - we should probably *remove* quite a few.
    > >
    > > For example 'firmware/' was recently moved to drivers/firmware/, and in a
    > > similar fashion about a third of the remaining 22 directories should
    > > probably be moved too:
    > >
    > > drwxr-xr-x arch
    > > drwxr-xr-x block
    > > drwxr-xr-x certs # move to build/certs/ dir
    > > drwxr-xr-x crypto # move to kernel/crypto/ or security/crypto/
    > > drwxr-xr-x Documentation
    > > drwxr-xr-x drivers
    > > drwxr-xr-x fs
    > > drwxr-xr-x include
    > > drwxr-xr-x init
    > > drwxr-xr-x ipc # move to kernel/ipc/
    > > drwxr-xr-x kernel
    > > drwxr-xr-x lib
    > > drwxr-xr-x LICENSES
    > > drwxr-xr-x mm
    > > drwxr-xr-x net
    > > drwxr-xr-x samples # move to Documentation/samples/
    > > drwxr-xr-x scripts # move to build/scripts/
    > > drwxr-xr-x security
    > > drwxr-xr-x sound # move to drivers/sound/
    > > drwxr-xr-x tools
    > > drwxr-xr-x usr # move to build/usr/
    > > drwxr-xr-x virt # move to the already existing drivers/virt/
    > >
    > > -rw-r--r-- COPYING
    > > -rw-r--r-- CREDITS
    > > -rw-r--r-- Kbuild
    > > -rw-r--r-- Kconfig
    > > -rw-r--r-- MAINTAINERS
    > > -rw-r--r-- Makefile
    > > -rw-r--r-- README
    > >
    > > There's a few borderline ones:
    > >
    > > - 'block' could in principle move to drivers/block/core/ but it's fine
    > > at the top level too I think.
    > >
    > > - 'init' could in principle be moved to kernel/init/ - but it's not
    > > wrong at the top level either.
    > >
    > > The remaining top level hierarchy would look pretty sweet and short:
    > >
    > > drwxr-xr-x arch
    > > drwxr-xr-x block
    > > drwxr-xr-x build # new
    > > drwxr-xr-x Documentation
    > > drwxr-xr-x drivers
    > > drwxr-xr-x fs
    > > drwxr-xr-x include
    > > drwxr-xr-x init
    > > drwxr-xr-x kernel
    > > drwxr-xr-x lib
    > > drwxr-xr-x LICENSES
    > > drwxr-xr-x mm
    > > drwxr-xr-x net
    > > drwxr-xr-x security
    > > drwxr-xr-x tools
    > >
    > > -rw-r--r-- COPYING
    > > -rw-r--r-- CREDITS
    > > -rw-r--r-- Kbuild
    > > -rw-r--r-- Kconfig
    > > -rw-r--r-- MAINTAINERS
    > > -rw-r--r-- Makefile
    > > -rw-r--r-- README
    > >
    > > I'm volunteering to do this (in a scripted, repeatable, reviewable,
    > > tweakable and "easy to execute in a quiet moment" fashion), although
    > > I also expect you to balk at the churn. :-)
    >
    > I for one would love the above changes. And I'm the one that has to
    > deal with all of the backporting issues that arise with stable backports :)

    Oh, that's a pleasant surprise, I didn't expect _100%_ support! :-)

    So I started working on this today and whipped up three of these
    movements, in a 100% scripted fashion.

    You can have a sneak preview at the result in this tree:

    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/toplevel

    ...

    2515 files changed, 42476 insertions(+), 42476 deletions(-)

    I decided not to post these first patches to lkml, because many of the
    patches are unreviewably large even with smart rename detection. Even the
    diffstat was 5,000+ lines so I abbreviated it ...

    The tree has 6 commits for now:

    6576382877c0: toplevel: Move ipc/ to kernel/ipc/
    8f7ace98971a: toplevel: Fix up kernel/ipc/ movement effects
    cc703bc54b00: toplevel: Move sound/ to drivers/sound/
    a63bdbd797da: toplevel: Fix up drivers/sound/ movement effects
    28adaae5ae8f: toplevel: Move samples/ to Documentation/samples/
    4e9f67e3bc48: toplevel: Fix up samples/ movement effects

    Due to the scripting all the commits are auto-generated for the time
    being - without SOB lines and proper changelogs, etc.

    Note that each movement action consists of two commits:

    cc703bc54b00: toplevel: Move sound/ to drivers/sound/
    a63bdbd797da: toplevel: Fix up drivers/sound/ movement effects

    The first one is just the result of the 'git mv', which gets most of the
    noise.

    The second one fixes up the build system, Kconfig system and any
    references to the old file names. Forward and backward porting of patches
    across the rename boundary is in most cases a simple matter of fixing up
    the file names in the patches - I'll put both forward and backward
    patch-consersion one-liner scripts for that into the changelog itself.

    I believe this is easier to review, but it has the disadvantage that
    bisection will trivially break if it hits any of the base commits. Can
    combine the commits as well, or can add a suggestion to use
    "git bisect next" to the changelog itself. Either approach is fine to me.

    Anyway, I will fix the aforementioned details, but wanted to show the
    gist of these changes and give you an opportunity to request changes,
    before I go down this path too much.

    The tree is functional here after some light testing - will put it
    through more rigorous testing before posting future iterations.

    The advantage of the scripting is that:

    - I can re-run this on any base tree and with any granularity, and my
    scripts also have some sanity checks to see whether any old filename
    patterns escaped the conversion, etc.

    - The order of the movement is discretionary as well, i.e. if you prefer
    the sound/ movement in a single tree and at a specific time, that all
    can be phased arbitrarily.

    - The scripts can be re-run with less than a minute of runtime, so it
    can all be timed for maximum convenience to you, Linus and affected
    maintainers.

    Is this close to what you had in mind?

    Thanks,

    Ingo

    ------------------>
    Ingo Molnar (6):
    toplevel: Move ipc/ to kernel/ipc/
    toplevel: Fix up kernel/ipc/ movement effects
    toplevel: Move sound/ to drivers/sound/
    toplevel: Fix up drivers/sound/ movement effects
    toplevel: Move samples/ to Documentation/samples/
    toplevel: Fix up samples/ movement effects

    2515 files changed, 42476 insertions(+), 42476 deletions(-)

    \
     
     \ /
      Last update: 2019-09-23 22:09    [W:4.122 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site