[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dedd3fa5-5dc3-4ce1-9ab4-dc77e23a6d7d@default>
Date: Wed, 1 Jun 2011 09:22:59 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Konrad Wilk <konrad.wilk@...cle.com>
Subject: RE: next phase of tmem into linux-next
> On Tue, 31 May 2011 17:49:21 -0700 (PDT) Dan Magenheimer
> <dan.magenheimer@...cle.com> wrote:
> >
> > Please re-include the following tree into linux-next. The
> > commit series is for frontswap, the complement of cleancache
> > handling swap pages, which is the next phase in tmem. It also
> > includes the shim code to Xen tmem for frontswap. It applies
> > cleanly on linux-3.0-rc1, but if there are any problems or
> > you have any questions, please let me know!
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem.git#linux-next
>
> I don't remove trees from linux-next unless excplictly asked to, so
> this
> tree is still included
Hi Stephen --
OK, I see "Already up-to-date" in merge.log. I'll assume
that the new frontswap commits will lag a day. (Thanks,
Konrad, for helping me find this info and pointing out the
probable lag.)
(A thought... perhaps the merge.log generation script should
do a "date" at the beginning and end, so one knows if one
has just missed your merge window?)
> As long as you stick to the rules (posted,
> reviewed, ready for Linus), anything you add to that tree will be
> included.
Yep, understood. Frontswap has been posted on lkml and tested for
over a year (and for nearly 2-1/2 years if counting earlier
versions as part of the original tmem postings), but hasn't gotten
as much attention because it was serialized behind merging of cleancache.
> The tree is still called "cleancache" in linux-next. Should I change
> that to something more generic?
Yes please. A good short name would be "tmem", but if you want
something longer and more descriptive maybe, "transcendent_memory".
I expect in the future that this might be the path for, for
example, tmem-related code that is promoted from drivers/staging.
E.g., the generic tmem.c code in drivers/staging/zcache could
probably end up in lib at some point if/when there are multiple users.
Thanks!
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/
Powered by blists - more mailing lists