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:   Sun, 22 Sep 2019 13:25:55 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Mark Brown <broonie@...nel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Anders Roxell <anders.roxell@...aro.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Kselftest update for Linux 5.4-rc1


* 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. :-)

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ