linux-kernel - Re: [GIT PULL] Kselftest update for Linux 5.4-rc1

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]
Message-ID: <0ab5da69-e4f2-8990-20f9-354461235581@linuxfoundation.org>
Date:   Mon, 23 Sep 2019 08:44:37 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        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>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [GIT PULL] Kselftest update for Linux 5.4-rc1

On 9/22/19 5:52 AM, Greg KH 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 :)
> 

I am exploring the possibility to move selftests to a better location
or add a git alias so it can be found easily. With the addition of KUnit
and future work that is planned to connect kselftest and KUnit, it would
make sense have selftests to be in a location that is better suited than
where it currently resides.

I have been getting feedback from some developers that they would like
to see selftests more visible and easier to find.

There are some dependencies (unintended, shouldn't exist) between some
tests and content under tools that might pose some logistical problems,
in addition to the churn of backporting.

I haven't explored "git alias" yet though. Since this topic of moving
came up, I would liek to get feedback on selftests location in general
and where would be a good place for it.

thanks,
-- Shuah