From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@qumranet.com>,
Hugh Dickins <hugh@veritas.com>, Robin Holt <holt@sgi.com>,
Avi Kivity <avi@qumranet.com>, Izik Eidus <izike@qumranet.com>,
kvm-devel@lists.sourceforge.net, general@lists.openfabrics.org,
Steve Wise <swise@opengridcomputing.com>,
Roland Dreier <rdreier@cisco.com>,
Kanoj Sarcar <kanojsarcar@yahoo.com>,
steiner@sgi.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, daniel.blueman@quadrics.com,
Nick Piggin <npiggin@suse.de>
Subject: Re: EMM: Fixup return value handling of emm_notify()
Date: Thu, 03 Apr 2008 12:40:46 +0200 [thread overview]
Message-ID: <1207219246.8514.817.camel@twins> (raw)
In-Reply-To: <Pine.LNX.4.64.0804021427210.30516@schroedinger.engr.sgi.com>
On Wed, 2008-04-02 at 14:33 -0700, Christoph Lameter wrote:
> On Wed, 2 Apr 2008, Andrea Arcangeli wrote:
>
> > but anyway it's silly to be hardwired to such an interface that worst
> > of all requires switch statements instead of proper pointer to
> > functions and a fixed set of parameters and retval semantics for all
> > methods.
>
> The EMM API with a single callback is the simplest approach at this point.
> A common callback for all operations allows the driver to implement common
> entry and exit code as seen in XPMem.
It seems to me that common code can be shared using functions? No need
to stuff everything into a single function. We have method vectors all
over the kernel, we could do a_ops as a single callback too, but we
dont.
FWIW I prefer separate methods.
> I guess we can complicate this more by switching to a different API or
> adding additional emm_xxx() callback if need be but I really want to have
> a strong case for why this would be needed. There is the danger of
> adding frills with special callbacks in this and that situation that could
> make the notifier complicated and specific to a certain usage scenario.
>
> Having this generic simple interface will hopefully avoid such things.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Lameter <clameter@sgi.com>
Cc: Nick Piggin <npiggin@suse.de>,
steiner@sgi.com, Andrea Arcangeli <andrea@qumranet.com>,
linux-mm@kvack.org, Izik Eidus <izike@qumranet.com>,
Kanoj Sarcar <kanojsarcar@yahoo.com>,
Roland Dreier <rdreier@cisco.com>,
linux-kernel@vger.kernel.org, Avi Kivity <avi@qumranet.com>,
kvm-devel@lists.sourceforge.net, daniel.blueman@quadrics.com,
Robin Holt <holt@sgi.com>,
general@lists.openfabrics.org, Hugh Dickins <hugh@veritas.com>
Subject: [ofa-general] Re: EMM: Fixup return value handling of emm_notify()
Date: Thu, 03 Apr 2008 12:40:46 +0200 [thread overview]
Message-ID: <1207219246.8514.817.camel@twins> (raw)
In-Reply-To: <Pine.LNX.4.64.0804021427210.30516@schroedinger.engr.sgi.com>
On Wed, 2008-04-02 at 14:33 -0700, Christoph Lameter wrote:
> On Wed, 2 Apr 2008, Andrea Arcangeli wrote:
>
> > but anyway it's silly to be hardwired to such an interface that worst
> > of all requires switch statements instead of proper pointer to
> > functions and a fixed set of parameters and retval semantics for all
> > methods.
>
> The EMM API with a single callback is the simplest approach at this point.
> A common callback for all operations allows the driver to implement common
> entry and exit code as seen in XPMem.
It seems to me that common code can be shared using functions? No need
to stuff everything into a single function. We have method vectors all
over the kernel, we could do a_ops as a single callback too, but we
dont.
FWIW I prefer separate methods.
> I guess we can complicate this more by switching to a different API or
> adding additional emm_xxx() callback if need be but I really want to have
> a strong case for why this would be needed. There is the danger of
> adding frills with special callbacks in this and that situation that could
> make the notifier complicated and specific to a certain usage scenario.
>
> Having this generic simple interface will hopefully avoid such things.
>
>
next prev parent reply other threads:[~2008-04-03 10:41 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-01 20:55 [patch 0/9] [RFC] EMM Notifier V2 Christoph Lameter
2008-04-01 20:55 ` [ofa-general] " Christoph Lameter
2008-04-01 20:55 ` [patch 1/9] EMM Notifier: The notifier calls Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-01 21:14 ` Peter Zijlstra
2008-04-01 21:38 ` Paul E. McKenney
2008-04-02 17:44 ` Christoph Lameter
2008-04-02 18:43 ` EMM: Fix rcu handling and spelling Christoph Lameter
2008-04-02 19:02 ` Paul E. McKenney
2008-04-02 6:49 ` [patch 1/9] EMM Notifier: The notifier calls Andrea Arcangeli
2008-04-02 6:49 ` [ofa-general] " Andrea Arcangeli
2008-04-02 10:59 ` Robin Holt
2008-04-02 10:59 ` [ofa-general] " Robin Holt
2008-04-02 11:16 ` Andrea Arcangeli
2008-04-02 11:16 ` Andrea Arcangeli
2008-04-02 14:26 ` Robin Holt
2008-04-02 17:59 ` Christoph Lameter
2008-04-02 17:59 ` [ofa-general] " Christoph Lameter
2008-04-02 19:03 ` EMM: Fixup return value handling of emm_notify() Christoph Lameter
2008-04-02 19:03 ` [ofa-general] " Christoph Lameter
2008-04-02 21:25 ` Andrea Arcangeli
2008-04-02 21:25 ` [ofa-general] " Andrea Arcangeli
2008-04-02 21:33 ` Christoph Lameter
2008-04-02 21:33 ` [ofa-general] " Christoph Lameter
2008-04-03 10:40 ` Peter Zijlstra [this message]
2008-04-03 10:40 ` Peter Zijlstra
2008-04-03 15:00 ` Andrea Arcangeli
2008-04-03 15:00 ` [ofa-general] " Andrea Arcangeli
2008-04-03 19:14 ` Christoph Lameter
2008-04-03 19:14 ` [ofa-general] " Christoph Lameter
2008-04-02 21:05 ` EMM: Require single threadedness for registration Christoph Lameter
2008-04-02 21:05 ` [ofa-general] " Christoph Lameter
2008-04-02 22:01 ` Andrea Arcangeli
2008-04-02 22:01 ` [ofa-general] " Andrea Arcangeli
2008-04-02 22:06 ` Christoph Lameter
2008-04-02 22:06 ` [ofa-general] " Christoph Lameter
2008-04-02 22:17 ` Andrea Arcangeli
2008-04-02 22:17 ` [ofa-general] " Andrea Arcangeli
2008-04-02 22:41 ` Christoph Lameter
2008-04-02 22:41 ` [ofa-general] " Christoph Lameter
2008-04-03 1:24 ` EMM: disable other notifiers before register and unregister Christoph Lameter
2008-04-03 1:24 ` Christoph Lameter
2008-04-03 10:40 ` Peter Zijlstra
2008-04-03 10:40 ` [ofa-general] " Peter Zijlstra
2008-04-03 15:29 ` Andrea Arcangeli
2008-04-03 19:20 ` Christoph Lameter
2008-04-03 19:20 ` [ofa-general] " Christoph Lameter
2008-04-03 20:23 ` Christoph Lameter
2008-04-04 12:30 ` Andrea Arcangeli
2008-04-04 12:30 ` Andrea Arcangeli
2008-04-04 20:20 ` [PATCH] mmu notifier #v11 Andrea Arcangeli
2008-04-04 20:20 ` [ofa-general] " Andrea Arcangeli
2008-04-04 22:06 ` Christoph Lameter
2008-04-05 0:23 ` Andrea Arcangeli
2008-04-05 0:23 ` [ofa-general] " Andrea Arcangeli
2008-04-07 5:45 ` Christoph Lameter
2008-04-07 5:45 ` Christoph Lameter
2008-04-07 6:02 ` Andrea Arcangeli
2008-04-07 6:02 ` [ofa-general] " Andrea Arcangeli
2008-04-02 21:53 ` [patch 1/9] EMM Notifier: The notifier calls Andrea Arcangeli
2008-04-02 21:53 ` [ofa-general] " Andrea Arcangeli
2008-04-02 21:54 ` Christoph Lameter
2008-04-02 21:54 ` [ofa-general] " Christoph Lameter
2008-04-02 22:09 ` Andrea Arcangeli
2008-04-02 22:09 ` [ofa-general] " Andrea Arcangeli
2008-04-02 23:04 ` Christoph Lameter
2008-04-02 23:04 ` [ofa-general] " Christoph Lameter
2008-04-01 20:55 ` [patch 2/9] Move tlb flushing into free_pgtables Christoph Lameter
2008-04-01 20:55 ` [ofa-general] " Christoph Lameter
2008-04-01 20:55 ` [patch 3/9] Convert i_mmap_lock to i_mmap_sem Christoph Lameter
2008-04-01 20:55 ` [ofa-general] " Christoph Lameter
2008-04-01 20:55 ` [patch 4/9] Remove tlb pointer from the parameters of unmap vmas Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-01 20:55 ` [patch 5/9] Convert anon_vma lock to rw_sem and refcount Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-02 17:50 ` Andrea Arcangeli
2008-04-02 17:50 ` Andrea Arcangeli
2008-04-02 18:15 ` Christoph Lameter
2008-04-02 18:15 ` Christoph Lameter
2008-04-02 21:56 ` Andrea Arcangeli
2008-04-02 21:56 ` [ofa-general] " Andrea Arcangeli
2008-04-02 21:56 ` Christoph Lameter
2008-04-02 21:56 ` [ofa-general] " Christoph Lameter
2008-04-02 22:12 ` Andrea Arcangeli
2008-04-02 22:12 ` [ofa-general] " Andrea Arcangeli
2008-04-01 20:55 ` [patch 6/9] This patch exports zap_page_range as it is needed by XPMEM Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-01 20:55 ` [patch 7/9] Locking rules for taking multiple mmap_sem locks Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-01 20:55 ` [patch 8/9] XPMEM: The device driver Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
2008-04-01 20:55 ` [patch 9/9] XPMEM: Simple example Christoph Lameter
2008-04-01 20:55 ` Christoph Lameter
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=1207219246.8514.817.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=andrea@qumranet.com \
--cc=avi@qumranet.com \
--cc=clameter@sgi.com \
--cc=daniel.blueman@quadrics.com \
--cc=general@lists.openfabrics.org \
--cc=holt@sgi.com \
--cc=hugh@veritas.com \
--cc=izike@qumranet.com \
--cc=kanojsarcar@yahoo.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=rdreier@cisco.com \
--cc=steiner@sgi.com \
--cc=swise@opengridcomputing.com \
/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.