Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Sun, Sep 22, 2019 at 8:26 PM Ingo Molnar wrote: > > > * Linus Torvalds wrote: > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > 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-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xipc # move to kernel/ipc/ > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsamples # move to Documentation/samples/ > drwxr-xr-xscripts # move to build/scripts/ > drwxr-xr-xsecurity > drwxr-xr-xsound # move to drivers/sound/ > drwxr-xr-xtools > drwxr-xr-xusr # move to build/usr/ > drwxr-xr-xvirt# 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-xarch > drwxr-xr-xblock > drwxr-xr-xbuild # 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-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsecurity > drwxr-xr-xtools > > -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 -- Best Regards Masahiro Yamada
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
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-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xipc # move to kernel/ipc/ > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsamples # move to Documentation/samples/ > drwxr-xr-xscripts # move to build/scripts/ > drwxr-xr-xsecurity > drwxr-xr-xsound # 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
The pull request you sent on Mon, 23 Sep 2019 16:40:15 -0600: > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest > tags/linux-kselftest-5.4-rc1.1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/797a3242755da1b7c1ada6fb153cb2700ef30a80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > 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-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # 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? :)
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
* tim.b...@sony.com wrote: > > -Original Message- > > From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM > > > > * Linus Torvalds wrote: > > > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > > 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-xarch > > drwxr-xr-xblock > > drwxr-xr-xcerts # move to build/certs/ dir > > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > > drwxr-xr-xDocumentation > > drwxr-xr-xdrivers > > drwxr-xr-xfs > > drwxr-xr-xinclude > > drwxr-xr-xinit > > drwxr-xr-xipc # move to kernel/ipc/ > > drwxr-xr-xkernel > > drwxr-xr-xlib > > drwxr-xr-xLICENSES > > drwxr-xr-xmm > > drwxr-xr-xnet > > drwxr-xr-xsamples # move to Documentation/samples/ > > drwxr-xr-xscripts # 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
RE: [GIT PULL] Kselftest update for Linux 5.4-rc1
> -Original Message- > From: Ingo Molnar on Sunday, September 22, 2019 1:26 AM > > * Linus Torvalds wrote: > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > 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-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xipc # move to kernel/ipc/ > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsamples # move to Documentation/samples/ > drwxr-xr-xscripts # 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 ...
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On 9/23/19 2:53 PM, Ingo Molnar wrote: * Shuah Khan 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
* Shuah Khan 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On 9/23/19 1:52 PM, Randy Dunlap wrote: On 9/23/19 12:43 PM, Ingo Molnar wrote: * Shuah Khan 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On 9/23/19 12:43 PM, Ingo Molnar wrote: > > * Shuah Khan 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/. -- ~Randy
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
* Shuah Khan 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
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 wrote: On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins 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-xarch drwxr-xr-xblock drwxr-xr-xcerts # move to build/certs/ dir drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xipc # move to kernel/ipc/ drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsamples # move to Documentation/samples/ drwxr-xr-xscripts # move to build/scripts/ drwxr-xr-xsecurity drwxr-xr-xsound # move to drivers/sound/ drwxr-xr-xtools drwxr-xr-xusr # move to build/usr/ drwxr-xr-xvirt# 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-xarch drwxr-xr-xblock drwxr-xr-xbuild # new drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsecurity drwxr-xr-xtools -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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file > hierarchies annoy kernel developers Flat(ish) file hierarchies are good -- less typing. If you're copy-pasting then it doesn't matter much (it still matters a little because long filename occupy more space on the screen and in logs). > makes it harder for newbies to understand the kernel source as well. That's fine too. > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ No, crypto/ is fine. If everything arch independent should live at kernel/ then why should kernel/ exist at all? It should be trimmed and everything moved to the top level directory (OK, I'm not really suggesting that). > drwxr-xr-xipc # move to kernel/ipc/ No, same reason. It was there since time immemorial. > drwxr-xr-xsamples # move to Documentation/samples/ Just delete it. Best API usage samples are in modern parts of main tree, actively maintained/updated. > drwxr-xr-xscripts # move to build/scripts/ eh > drwxr-xr-xsound # move to drivers/sound/ NO! it has hw independent part and pretty big one. > drwxr-xr-xtools If tools/ people could somewhow stop duplicating large parts of include/linux and arch/x86/include/asm it will be very much appreciated. > - 'block' could in principle move to drivers/block/core/ but it's fine >at the top level too I think. It is fine indeed. Short name, top level dir, arch and hw independent code -- it is perfect. > 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. :-) Can I pay you $100 to not do this ever? In Russia we say "what has grown has grown" and it is not like Linux is perfect example of intelligent design.
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > 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-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xipc # move to kernel/ipc/ > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsamples # move to Documentation/samples/ > drwxr-xr-xscripts # move to build/scripts/ > drwxr-xr-xsecurity > drwxr-xr-xsound # move to drivers/sound/ > drwxr-xr-xtools > drwxr-xr-xusr # move to build/usr/ > drwxr-xr-xvirt# 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-xarch > drwxr-xr-xblock > drwxr-xr-xbuild # new > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsecurity > drwxr-xr-xtools > > -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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
* Linus Torvalds wrote: > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > 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-xarch drwxr-xr-xblock drwxr-xr-xcerts # move to build/certs/ dir drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xipc # move to kernel/ipc/ drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsamples # move to Documentation/samples/ drwxr-xr-xscripts # move to build/scripts/ drwxr-xr-xsecurity drwxr-xr-xsound # move to drivers/sound/ drwxr-xr-xtools drwxr-xr-xusr # move to build/usr/ drwxr-xr-xvirt# 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-xarch drwxr-xr-xblock drwxr-xr-xbuild # new drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsecurity drwxr-xr-xtools -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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Fri, Sep 20, 2019 at 11:15 AM Linus Torvalds wrote: > > On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins > 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!
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Fri, Sep 20, 2019 at 11:03 AM Brendan Higgins 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On 9/20/19 10:51 AM, Linus Torvalds wrote: On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Fri, Sep 20, 2019 at 9:51 AM Linus Torvalds wrote: > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > 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`?
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Fri, Sep 20, 2019 at 9:27 AM Shuah Khan wrote:
>
> Hi Linus,
>
> On Fri, Sep 20, 2019, 10:18 AM Linus Torvalds
> wrote:
>>
>> On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan
>> 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", "drivers/" is "d" etc.
>>
>> It already doesn't work for everything ("mm/" is actually "mm"
>> 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
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On 9/20/19 9:17 AM, Linus Torvalds wrote:
> On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan 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", "drivers/" is "d" etc.
>
> It already doesn't work for everything ("mm/" is actually "mm"
> 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.
>
>> 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?
Please also move the top-level Kconfig menu item "KUnit support" to
somewhere that is not top-level. Maybe also in the lib/ menu. Maybe
in lib/Kconfig.debug.
--
~Randy
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan 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", "drivers/" is "d" etc.
It already doesn't work for everything ("mm/" is actually "mm"
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.
> 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?
Linus
