Re: [Tree, v2] De-clutter the top level directory, move ipc/ => kernel/ipc/, samples/ => Documentation/samples/ and sound/ => drivers/sound/

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

> Ingo Molnar <mingo@xxxxxxxxxx> 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