From: Pekka Enberg [mailto:penberg@kernel.org]
Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
[off-list ref] wrote:
quoted
Hmmm.. there's also zbud.c and tmem.c which are critical components
of both zcache and ramster. And there are header files as well which
will need to either be in mm/ or somewhere in include/linux/
Is there a reason or rule that mm/ can't have subdirectories?
Since zcache has at least three .c files plus ramster.c, and
since mm/frontswap.c and mm/cleancache.c are the foundation on
which all of these are built, I was thinking grouping all six
(plus headers) in the same mm/tmem/ subdirectory was a good
way to keep mm/ from continuing to get more cluttered... not counting
new zcache and ramster files, there are now 74 .c files in mm/!
(Personally, I think a directory has too many files in it if
"ls" doesn't fit in a 25x80 window.)
Thoughts?
There's no reason we can't have subdirectories. That said, I really
don't see the point of having a separate directory called 'tmem'. It
might make sense to have mm/zcache and/or mm/ramster but I suspect
you can just fold the core code in mm/zcache.c and mm/ramster.c by
slimming down the weird Solaris-like 'tmem' abstractions.
I'm not sure I understand... what is Solaris-like about tmem?
And what would you slim down?
While I agree one can often glom three separate 1000-line .c files
into a single 3000-line .c file, I recently spent some time moving
the other direction to, I thought, improve readability. Do kernel
developers have a preference for huge .c files rather than smaller
logically-separated moderate-sized files in a subdirectory?
Thanks,
Dan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>