linux-kernel - RE: [RFC/PATCH] zcache/ramster rewrite and promotion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ad942d93-489f-4bf4-96bc-8f65b1a23ea1@default>
Date:	Mon, 6 Aug 2012 09:10:26 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	Minchan Kim <minchan@...nel.org>,
	Nitin Gupta <ngupta@...are.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robert Jennings <rcj@...ux.vnet.ibm.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devel@...verdev.osuosl.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: RE: [RFC/PATCH] zcache/ramster rewrite and promotion

> From: Pekka Enberg [mailto:penberg@...nel.org]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
> 
> On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
> <dan.magenheimer@...cle.com> wrote:
> > I'm OK with placing it wherever kernel developers want to put
> > it, as long as the reason is not NIMBY-ness. [1]  My preference
> > is to keep all the parts together, at least for the review phase,
> > but if there is a consensus that it belongs someplace else,
> > I will be happy to move it.
> 
> I'd go for core code in mm/zcache.c and mm/ramster.c, and move the
> clustering code under net/ramster or drivers/ramster.

Hi Pekka --

Thanks for the quick feedback!

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?
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/