From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH v2 1/8] kvm tools: Add optional parameter used in ioport callbacks Date: Thu, 26 May 2011 12:38:56 +0300 Message-ID: <1306402736.3065.14.camel@lappy> References: <1306392135-16993-1-git-send-email-levinsasha928@gmail.com> <1306400009.16757.118.camel@jaguar> <1306400568.3065.8.camel@lappy> <1306401269.3065.12.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: john@jfloren.net, kvm@vger.kernel.org, mingo@elte.hu, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com To: Pekka Enberg Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:54453 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756902Ab1EZJjO (ORCPT ); Thu, 26 May 2011 05:39:14 -0400 Received: by wwa36 with SMTP id 36so552406wwa.1 for ; Thu, 26 May 2011 02:39:12 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2011-05-26 at 12:20 +0300, Pekka Enberg wrote: > On Thu, May 26, 2011 at 12:14 PM, Sasha Levin wrote: > >> > I've wanted to keep the original interface clean, Most of the IO port > >> > users don't (and probably won't) require a parameter. > >> > >> Well now struct ioport_operations isn't very clean is it - or the code > >> that needs to determine which function pointer to call?-) > > > > struct ioport_operations is a bit more messy, but it's one spot instead > > of adding a 'parameter' to each module that doesn't really need it. > > > > My assumption is that most ioport users now and in the future won't need > > it, it just solves several special cases more easily (multiple devices > > which share same handling functions). > > Hey, that's not an excuse to make struct ioport_operations 'bit > messy'! Look at any kernel code that uses ops like we do here and you > will see we don't do APIs like this. > > One option here is to rename 'struct ioport_entry' to 'struct ioport' > and pass a pointer to that as the first argument to all of the ops. > That's what most APIs in the kernel do anyway. Why do it like that? this way users of the callback functions will need to know the internal structure of struct ioport_entry. -- Sasha.