[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c5c17e83-a21c-4360-a201-3bb865062961@default>
Date: Mon, 24 May 2010 19:15:59 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: chris.mason@...cle.com, akpm@...ux-foundation.org, adilger@....com,
tytso@....edu, mfasheh@...e.com, joel.becker@...cle.com,
matthew@....cx, linux-btrfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, ocfs2-devel@....oracle.com,
linux-mm@...ck.org, ngupta@...are.org, jeremy@...p.org,
JBeulich@...ell.com, kurt.hackel@...cle.com, npiggin@...e.de,
dave.mccracken@...cle.com, riel@...hat.com
Subject: RE: Cleancache [PATCH 2/7] (was Transcendent Memory): core files
> > The third one is pgoff_t; again, use sane types, _if_ you actually
> want
> > the argument #3 at all - it can be derived from struct page you are
> > passing there as well.
>
> I thought it best to declare the _ops so that the struct page
> is opaque to the "backend" (driver). The kernel-side ("frontend")
> defines the handle and ensures coherency, so the backend shouldn't
> be allowed to derive or muck with the three-tuple passed by the
> kernel. In the existing (Xen tmem) driver, the only operation
> performed on the struct page parameter is page_to_pfn(). OTOH,
> I could go one step further and pass a pfn_t instead of a
> struct page, since it is really only the physical page frame that
> the backend needs to know about and (synchronously) read/write from/to.
>
> Thoughts?
Silly me. pfn_t is a Xen/KVM type not otherwise used in the
kernel AFAICT. Please ignore...
--
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