From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: [ofa-general] Re: EMM: Fixup return value handling of emm_notify() Date: Thu, 03 Apr 2008 12:40:46 +0200 Message-ID: <1207219246.8514.817.camel@twins> References: <20080401205531.986291575@sgi.com> <20080401205635.793766935@sgi.com> <20080402064952.GF19189@duo.random> <20080402212515.GS19189@duo.random> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: general-bounces@lists.openfabrics.org Errors-To: general-bounces@lists.openfabrics.org To: Christoph Lameter Cc: Nick Piggin , steiner@sgi.com, Andrea Arcangeli , linux-mm@kvack.org, Izik Eidus , Kanoj Sarcar , Roland Dreier , linux-kernel@vger.kernel.org, Avi Kivity , kvm-devel@lists.sourceforge.net, daniel.blueman@quadrics.com, Robin Holt , general@lists.openfabrics.org, Hugh Dickins List-Id: linux-mm.kvack.org 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. > >