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]

Date:	Sat, 4 Aug 2012 11:57:27 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Seth Jennings <sjenning@...ux.vnet.ibm.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

Hi Konrad,

> On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
>> Why on earth would you want to move that under the mm directory?

On Wed, Aug 1, 2012 at 12:04 AM, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com> wrote:
> If you take aside that problem that it is one big patch instead
> of being split up in more reasonable pieces - would you recommend
> that it reside in a different directory?
>
> Or is that it does not make sense b/c it has other components in it - such
> as tcp/nodemaneger/hearbeat/etc so it should go under the refactor knife?
>
> And if you rip out the ramster from this and just concentrate on zcache -
> should that go in drivers/mm or mm/tmem/zcache?

I definitely think mm/zcache.c makes sense. I hate the fact that it's
now riddled with references to "tmem" and "ramster" but that's probably
fixable. I also hate the fact that you've now gone and rewritten
everything so we lose all the change history zcache has had under
staging.

As for ramster, it might make sense to have its core in mm/ramster.c and
move the TCP weirdness somewhere else. The exact location depends on
what kind of userspace ABIs you expose, I suppose. I mean, surely you
need to configure the thing somehow?

                        Pekka
--
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/