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