* Eric W. Biederman <ebied...@xmission.com> wrote:
> Ingo Molnar <mi...@kernel.org> writes:
>
> > - Split it into finer grained steps (3 instead of 2 patches per
> > movement), for easier review and bisection testing:
> >
> > toplevel: Move ipc/ to kernel/ipc/: move the files
> > toplevel: Move ipc/ to kernel/ipc/: adjust the build system
> > toplevel: Move ipc/ to kernel/ipc/: adjust comments and documentation
>
> Can we not mess with ipc/ please.
>
> I know that will mess with my muscle memory and I don't see the point.
> Especially as long as it is named ipc and not sysvipc.
>
> A half cleanup really looks worse than a real cleanup.
>
> SysV IPC really is a side car on the kernel and on unix in general
> and having the directory structure reflect that seems completely sensible.
While such objections are I think valid for scripts/, the situation is
very different for ipc/:
- ipc/ is a tiny subsystem of just ~9k lines of code, and it's in the
top level directory for historical reasons.
- ipc/ is an established subsystem of old interfaces with comparatively
very few changes these days: there were just about 16 commits added in
the last 12 months that changed the code and had 'ipc' in the title.
Somewhat ironically, the biggest commit of all was a "system call
renaming" commit:
275f22148e87: ipc: rename old-style shmctl/semctl/msgctl syscalls
14 files changed, 137 insertions(+), 62 deletions(-)
Many of the remaining 15 commits were simple in nature - and there
were 9 different authors, i.e. the per author frequency of changes for
ipc/ is even lower: around one per year for those 9 developers who are
interested in ipc/ changes. I doubt there's much muscle memory even
for them as a result.
- The 'muscle memory' argument has to be weighted by probability of
interest (linecount), probability of change (frequency of commits) and
number of authors. These factors add up to a very low change frequency
for ipc/. We've moved and consolidated much, much bigger and higher
frequency subsystems in the recent past, such as kernel/sched/ or
kernel/locking/.
- The ipc/ location is arguably random and idiosynchratic - it's a
leftover from old times nobody really bothered to clean up - but that
fact shouldn't be a permanent barrier IMO.
- While uncluttering the top level directory for aesthethic and
documentation reasons is one technical factor, there's another reason
for my ipc/ movement: I have the secret hope to be able to move init/
to kernel/init/ as well, in which case there's a big muscle memory
advantage for the future: 'i<tab>' would expand to include/ in a
single step! :-) Now *that* is perhaps the highest frequency muscle
memory location in the kernel. ;-)
Or looking at it from another angle: if we applied your ipc/ benchmark
then basically almost *nothing* could be moved from the toplevel
directory or any other location, pretty much *ever*.
Thanks,
Ingo
