From: William Lee Irwin III <wli@holomorphy.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Adam Litke <agl@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Ken Chen <kenchen@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] Introduce the pagetable_operations and associated helper macros.
Date: Tue, 20 Mar 2007 21:52:14 -0700 [thread overview]
Message-ID: <20070321045214.GE2986@holomorphy.com> (raw)
In-Reply-To: <4600B216.3010505@yahoo.com.au>
Adam Litke wrote:
>> struct vm_operations_struct * vm_ops;
>> + const struct pagetable_operations_struct * pagetable_ops;
On Wed, Mar 21, 2007 at 03:18:30PM +1100, Nick Piggin wrote:
> Can you remind me why this isn't in vm_ops?
> Also, it is going to be hugepage-only, isn't it? So should the naming be
> changed to reflect that? And #ifdef it...
ISTR potential ppc64 users coming out of the woodwork for something I
didn't recognize the name of, but I may be confusing that with your
patch. I can implement additional users (and useful ones at that)
needing this in particular if desired.
Adam Litke wrote:
>> +struct pagetable_operations_struct {
>> + int (*fault)(struct mm_struct *mm,
On Wed, Mar 21, 2007 at 03:18:30PM +1100, Nick Piggin wrote:
> I got dibs on fault ;)
> My callback is a sanitised one that basically abstracts the details of the
> virtual memory mapping away, so it is usable by drivers and filesystems.
> You actually want to bypass the normal fault handling because it doesn't
> know how to deal with your virtual memory mapping. Hmm, the best suggestion
> I can come up with is handle_mm_fault... unless you can think of a better
> name for me to use.
Two fault handling methods callbacks raise an eyebrow over here at least.
I was vaguely hoping for unification of the fault handling callbacks.
-- wli
WARNING: multiple messages have this Message-ID (diff)
From: William Lee Irwin III <wli@holomorphy.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Adam Litke <agl@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Ken Chen <kenchen@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] Introduce the pagetable_operations and associated helper macros.
Date: Tue, 20 Mar 2007 21:52:14 -0700 [thread overview]
Message-ID: <20070321045214.GE2986@holomorphy.com> (raw)
In-Reply-To: <4600B216.3010505@yahoo.com.au>
Adam Litke wrote:
>> struct vm_operations_struct * vm_ops;
>> + const struct pagetable_operations_struct * pagetable_ops;
On Wed, Mar 21, 2007 at 03:18:30PM +1100, Nick Piggin wrote:
> Can you remind me why this isn't in vm_ops?
> Also, it is going to be hugepage-only, isn't it? So should the naming be
> changed to reflect that? And #ifdef it...
ISTR potential ppc64 users coming out of the woodwork for something I
didn't recognize the name of, but I may be confusing that with your
patch. I can implement additional users (and useful ones at that)
needing this in particular if desired.
Adam Litke wrote:
>> +struct pagetable_operations_struct {
>> + int (*fault)(struct mm_struct *mm,
On Wed, Mar 21, 2007 at 03:18:30PM +1100, Nick Piggin wrote:
> I got dibs on fault ;)
> My callback is a sanitised one that basically abstracts the details of the
> virtual memory mapping away, so it is usable by drivers and filesystems.
> You actually want to bypass the normal fault handling because it doesn't
> know how to deal with your virtual memory mapping. Hmm, the best suggestion
> I can come up with is handle_mm_fault... unless you can think of a better
> name for me to use.
Two fault handling methods callbacks raise an eyebrow over here at least.
I was vaguely hoping for unification of the fault handling callbacks.
-- wli
--
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>
next prev parent reply other threads:[~2007-03-21 4:55 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 20:05 [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2) Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-19 20:05 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-20 23:24 ` Dave Hansen
2007-03-20 23:24 ` Dave Hansen
2007-03-21 14:50 ` Adam Litke
2007-03-21 14:50 ` Adam Litke
2007-03-21 15:05 ` Arjan van de Ven
2007-03-21 15:05 ` Arjan van de Ven
2007-03-21 4:18 ` Nick Piggin
2007-03-21 4:18 ` Nick Piggin
2007-03-21 4:52 ` William Lee Irwin III [this message]
2007-03-21 4:52 ` William Lee Irwin III
2007-03-21 5:07 ` Nick Piggin
2007-03-21 5:07 ` Nick Piggin
2007-03-21 5:41 ` William Lee Irwin III
2007-03-21 5:41 ` William Lee Irwin III
2007-03-21 6:51 ` Nick Piggin
2007-03-21 6:51 ` Nick Piggin
2007-03-21 7:36 ` Nick Piggin
2007-03-21 7:36 ` Nick Piggin
2007-03-21 10:46 ` William Lee Irwin III
2007-03-21 10:46 ` William Lee Irwin III
2007-03-21 15:17 ` Adam Litke
2007-03-21 15:17 ` Adam Litke
2007-03-21 16:00 ` Christoph Hellwig
2007-03-21 16:00 ` Christoph Hellwig
2007-03-21 23:03 ` Nick Piggin
2007-03-21 23:03 ` Nick Piggin
2007-03-21 23:02 ` Nick Piggin
2007-03-21 23:02 ` Nick Piggin
2007-03-21 23:32 ` William Lee Irwin III
2007-03-21 23:32 ` William Lee Irwin III
2007-03-19 20:05 ` [PATCH 2/7] copy_vma for hugetlbfs Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-19 20:05 ` [PATCH 3/7] pin_pages for hugetlb Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-19 20:05 ` [PATCH 4/7] unmap_page_range " Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-20 23:27 ` Dave Hansen
2007-03-20 23:27 ` Dave Hansen
2007-03-19 20:05 ` [PATCH 5/7] change_protection " Adam Litke
2007-03-19 20:05 ` Adam Litke
2007-03-19 20:06 ` [PATCH 6/7] free_pgtable_range " Adam Litke
2007-03-19 20:06 ` Adam Litke
2007-03-19 20:06 ` [PATCH 7/7] hugetlbfs fault handler Adam Litke
2007-03-19 20:06 ` Adam Litke
2007-03-20 23:50 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2) Dave Hansen
2007-03-20 23:50 ` Dave Hansen
2007-03-21 1:17 ` William Lee Irwin III
2007-03-21 1:17 ` William Lee Irwin III
2007-03-21 15:55 ` Hugh Dickins
2007-03-21 15:55 ` Hugh Dickins
2007-03-21 16:01 ` Christoph Hellwig
2007-03-21 16:01 ` Christoph Hellwig
2007-03-21 16:23 ` William Lee Irwin III
2007-03-21 17:08 ` Hugh Dickins
2007-03-21 17:42 ` William Lee Irwin III
2007-03-21 19:43 ` pagetable_ops: Hugetlb character device example Adam Litke
2007-03-21 19:43 ` Adam Litke
2007-03-21 19:51 ` Valdis.Kletnieks
2007-03-21 20:26 ` Adam Litke
2007-03-21 20:26 ` Adam Litke
2007-03-21 22:26 ` William Lee Irwin III
2007-03-21 22:26 ` William Lee Irwin III
2007-03-21 22:53 ` Matt Mackall
2007-03-21 22:53 ` Matt Mackall
2007-03-21 23:35 ` William Lee Irwin III
2007-03-21 23:35 ` William Lee Irwin III
2007-03-22 0:31 ` Matt Mackall
2007-03-22 0:31 ` Matt Mackall
2007-03-22 10:38 ` Christoph Hellwig
2007-03-22 10:38 ` Christoph Hellwig
2007-03-22 15:42 ` Mel Gorman
2007-03-22 15:42 ` Mel Gorman
2007-03-22 18:15 ` Christoph Hellwig
2007-03-22 18:15 ` Christoph Hellwig
2007-03-23 14:57 ` Mel Gorman
2007-03-23 14:57 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2007-02-19 18:31 [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Adam Litke
2007-02-19 18:31 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke
2007-02-19 18:31 ` Adam Litke
2007-02-19 18:41 ` Arjan van de Ven
2007-02-19 18:41 ` Arjan van de Ven
2007-02-19 19:31 ` Adam Litke
2007-02-19 19:31 ` Adam Litke
2007-02-19 19:48 ` William Lee Irwin III
2007-02-19 19:48 ` William Lee Irwin III
2007-02-19 22:29 ` Christoph Hellwig
2007-02-19 22:29 ` Christoph Hellwig
2007-02-20 15:50 ` Mel Gorman
2007-02-20 15:50 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070321045214.GE2986@holomorphy.com \
--to=wli@holomorphy.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=hch@infradead.org \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.