On Fri, Sep 20, 2019 at 9:27 AM Shuah Khan skhan@linuxfoundation.org wrote:
Hi Linus,
On Fri, Sep 20, 2019, 10:18 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan skhan@linuxfoundation.org wrote:
This Kselftest update for Linux 5.4-rc1 consists of several fixes to existing tests and adds KUnit, a lightweight unit testing and mocking framework for the Linux kernel from Brendan Higgins.
So I pulled this, but then I almost immediately unpulled it.
My reason for doing that may be odd, but it's because of the top-level 'kunit' directory. This shouldn't be on the top level.
The reason I react so strongly is that it actually breaks my finger memory. I don't type out filenames - I auto-compete them. So "kernel/" is "k<tab>", "drivers/" is "d<tab>" etc.
It already doesn't work for everything ("mm/" is actually "mm<tab>" not because we have files in the git tree, but because the build creates various "module" files), but this breaks a common pattern for me.
Sorry about that. I am surprised that none of the other reviewers brought this up.
On hindsight, I probably should have run this by you to get your feedback.
In the future KUnit will be linked to Kselftest framework to provide a way to trigger KUnit tests from user-space.
Can the kernel parts please move to lib/kunit/ or something like that.
I'm fine with lib/kunit/.
I will work with Brendan and come up with a plan and send another request early next week.
Cheers
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.
Part of it may be that the kernel is almost the _only_ project I work with, so unlike a lot of other developers, I end up having muscle memory for kernel-specific issues.
Auto-completion was also one of the (many) reasons why I hated CVS - having that annoying "CVS" directory there just always annoyed me. There's a reason why git uses a dot-file.
So I just have issues that perhaps other people don't react to as much. And aggressive tab-completion happens to be a thing for me.
Linus
On Fri, Sep 20, 2019 at 9:51 AM 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".
Heh.
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.
Well, it's good to know I'm not the first. :-)
Part of it may be that the kernel is almost the _only_ project I work with, so unlike a lot of other developers, I end up having muscle memory for kernel-specific issues.
Auto-completion was also one of the (many) reasons why I hated CVS - having that annoying "CVS" directory there just always annoyed me. There's a reason why git uses a dot-file.
Yuck. I have never used CVS myself, but the dot-file approach seems much more natural to me. Then again, I have been using git pretty much since I first started programming, so it's hard to say that I am not biased.
So I just have issues that perhaps other people don't react to as much. And aggressive tab-completion happens to be a thing for me.
Fair enough. On that note, are you okay with the `include/kunit/` directory, or do you want me to move it to `include/linux/kunit`?
On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins brendanhiggins@google.com wrote:
Fair enough. On that note, are you okay with the `include/kunit/` directory, or do you want me to move it to `include/linux/kunit`?
"include/kunit" should work just fine for me. At least I didn't react to it immediately when I had done my test-pull, and it doesn't change any auto-completion patterns for me either.
[ We already have two 'k' names under include, but even if that wasn't true, I don't type those names anyway so I wouldn't have had muscle-memory for those two directories in the first place.
Under include, it's "linux" (and to a smaller extent "asm-generic") that I autocomplete. ]
Linus
On Fri, Sep 20, 2019 at 11:15 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins brendanhiggins@google.com wrote:
Fair enough. On that note, are you okay with the `include/kunit/` directory, or do you want me to move it to `include/linux/kunit`?
"include/kunit" should work just fine for me. At least I didn't react to it immediately when I had done my test-pull, and it doesn't change any auto-completion patterns for me either.
Sounds good to me.
Thanks!
On 9/20/19 10:51 AM, Linus Torvalds 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.
Part of it may be that the kernel is almost the _only_ project I work with, so unlike a lot of other developers, I end up having muscle memory for kernel-specific issues.
Auto-completion was also one of the (many) reasons why I hated CVS - having that annoying "CVS" directory there just always annoyed me. There's a reason why git uses a dot-file.
So I just have issues that perhaps other people don't react to as much. And aggressive tab-completion happens to be a thing for me.
Thanks for explaining. Brendan and I will get this sorted out.
Looks like my previous response didn't make it to the kselftest and kernel lists.
thanks, -- Shuah
* 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. :-)
Thanks,
Ingo
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 :)
thanks,
greg k-h
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@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 :)
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
* Shuah Khan skhan@linuxfoundation.org wrote:
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.
I'm not sure about the Git alias thing - but I do agree that tools/testing/selftests is a pretty obscure location given the importance of kernel unit tests - and I think it could be moved one level higher, to tools/selftests? The "selftest" name already implies the "test" aspect after all.
Thanks,
Ingo
On 9/23/19 12:43 PM, Ingo Molnar wrote:
- Shuah Khan skhan@linuxfoundation.org wrote:
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.
I'm not sure about the Git alias thing - but I do agree that tools/testing/selftests is a pretty obscure location given the importance of kernel unit tests - and I think it could be moved one level higher, to tools/selftests? The "selftest" name already implies the "test" aspect after all.
Without trying to use too much paint, I would move testing/ to a top-level dir, outside of tools/, and leave selftest/ under testing/.
On 9/23/19 1:52 PM, Randy Dunlap wrote:
On 9/23/19 12:43 PM, Ingo Molnar wrote:
- Shuah Khan skhan@linuxfoundation.org wrote:
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.
I'm not sure about the Git alias thing - but I do agree that tools/testing/selftests is a pretty obscure location given the importance of kernel unit tests - and I think it could be moved one level higher, to tools/selftests? The "selftest" name already implies the "test" aspect after all.
Right. Obscure location given the importance is the problem.
Without trying to use too much paint, I would move testing/ to a top-level dir, outside of tools/, and leave selftest/ under testing/.
Right. What you suggesting is very similar to and more complete than what I have been thinking about and proposed at the KS kselftest track.
i.e move tools/testing/selftests to kselftest at the root level. I like your idea of moving tools/testing up to root and keep selftests under it.
If we are good with this kind of change, I would like to get this done sooner than later. There is some back-porting churn to worry about.
thanks, -- Shuah
* Shuah Khan skhan@linuxfoundation.org wrote:
Right. What you suggesting is very similar to and more complete than what I have been thinking about and proposed at the KS kselftest track.
i.e move tools/testing/selftests to kselftest at the root level. I like your idea of moving tools/testing up to root and keep selftests under it.
If we are good with this kind of change, I would like to get this done sooner than later. There is some back-porting churn to worry about.
I think the movement I suggested would be sufficient:
tools/testing/selftests/ => tools/selftests/
I.e. let's not clutter up the top level directory.
Thanks,
Ingo
On 9/23/19 2:53 PM, Ingo Molnar wrote:
- Shuah Khan skhan@linuxfoundation.org wrote:
Right. What you suggesting is very similar to and more complete than what I have been thinking about and proposed at the KS kselftest track.
i.e move tools/testing/selftests to kselftest at the root level. I like your idea of moving tools/testing up to root and keep selftests under it.
If we are good with this kind of change, I would like to get this done sooner than later. There is some back-porting churn to worry about.
I think the movement I suggested would be sufficient:
tools/testing/selftests/ => tools/selftests/
I.e. let's not clutter up the top level directory.
Yeah good point.
-- Shuah
-----Original Message----- From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM
- 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/
This one seems like it would break a lot of workflows, and contributor muscle memory and scripts. get_maintainer.pl and checkpatch.pl are probably in quite a few people's scripts.
Also, I'm not sure '/build' is the right destination for this. There are a lot more things in there than just build scripts. If you really want to remove the top level 'scripts', it might be best to put the scripts from top-level '/scripts' into '/tools/scripts', which is mostly empty now. -- Tim
... rest snipped ...
* Tim.Bird@sony.com Tim.Bird@sony.com wrote:
-----Original Message----- From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM
- 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/
This one seems like it would break a lot of workflows, and contributor muscle memory and scripts. get_maintainer.pl and checkpatch.pl are probably in quite a few people's scripts.
Also, I'm not sure '/build' is the right destination for this. There are a lot more things in there than just build scripts. If you really want to remove the top level 'scripts', it might be best to put the scripts from top-level '/scripts' into '/tools/scripts', which is mostly empty now.
Agreed - I'll leave it alone for now, because you are right that it's widely used.
Thanks,
Ingo
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/
For code with lots of history and active development, moving is quite counterproductive as it makes tracking a change tedious. Git can follow the path changes, but that's exactly the step I'd like not to do. That's similar to pure whitespace cleanup patches that are noise.
The decision for move should be IMO up to the maintainers of the code, that apparently worked for firmware/ -> drivers/firmware that has been mentioned. That's fine.
The muscle memory argument sounds quite weak to me, each of us has some habits, editor settings and coding style preferences, we will never agree. That's fine too.
The reason I'd find valid for moving is to reduce confusion when working with the files, not to promote a "formally correct classification" and hierarchy of directories that will stand in the way in the daily work.
Though I'm not directly affected by most of the proposed changes, I feel I should speak up before the file maneuvers reach code I care about.
- 'block' could in principle move to drivers/block/core/ but it's fine at the top level too I think.
Following that principle, we can move mm/ -> drivers/char/memory/ right? :)
Hi!
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/
Heh, I was always surprised that sound/ made it into top level... and no, I'd not mind it being moved away.
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.
net would also make sense as drivers/net/core... That is what inspired sound/ afaict.
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'd like to see that happen...
Best regards, Pavel
On Sun, Sep 22, 2019 at 8:26 PM Ingo Molnar mingo@kernel.org 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
I am opposed to the "build".
The build tools will go too deep, like build/scripts/kconfig ?
I often use checkpatch.pl, get_maintainer.pl etc.
Do I have to type build/scripts/checkpatch.pl ?
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
linux-kselftest-mirror@lists.linaro.org
-
Brendan Higgins -
David Sterba -
Greg KH -
Ingo Molnar -
Linus Torvalds -
Masahiro Yamada -
Pavel Machek -
Randy Dunlap -
Shuah Khan -
Tim.Bird＠sony.com