Date:   Mon, 23 Sep 2019 22:08:18 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>
Subject: [RFC, Tree] De-clutter the top level directory, move ipc/ =>
 kernel/ipc/, samples/ => Documentation/samples/ and sound/ => drivers/sound/


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

> On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
> > 
> > * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > 
> > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > > <brendanhiggins@...gle.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(-)

Powered by blists - more mailing lists