From: Sasha Levin <levinsasha928@gmail.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: john@jfloren.net, kvm@vger.kernel.org, mingo@elte.hu,
asias.hejun@gmail.com, gorcunov@gmail.com,
prasadjoshi124@gmail.com
Subject: Re: [PATCH v2 1/8] kvm tools: Add optional parameter used in ioport callbacks
Date: Thu, 26 May 2011 12:38:56 +0300 [thread overview]
Message-ID: <1306402736.3065.14.camel@lappy> (raw)
In-Reply-To: <BANLkTim2HSTU_Geg6UV=21b+D3GkenX93w@mail.gmail.com>
On Thu, 2011-05-26 at 12:20 +0300, Pekka Enberg wrote:
> On Thu, May 26, 2011 at 12:14 PM, Sasha Levin <levinsasha928@gmail.com> 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.
next prev parent reply other threads:[~2011-05-26 9:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-26 6:42 [PATCH v2 1/8] kvm tools: Add optional parameter used in ioport callbacks Sasha Levin
2011-05-26 6:42 ` [PATCH v2 2/8] kvm tools: Add basic ioport dynamic allocation Sasha Levin
2011-05-26 6:42 ` [PATCH v2 3/8] kvm tools: Use ioport context to control blk devices Sasha Levin
2011-05-26 6:42 ` [PATCH v2 4/8] kvm tools: Add support for multiple virtio-rng devices Sasha Levin
2011-05-26 6:42 ` [PATCH v2 5/8] kvm tools: Use dynamic IO port allocation in vesa driver Sasha Levin
2011-05-26 6:42 ` [PATCH v2 6/8] kvm tools: Use dynamic IO port allocation in 9p driver Sasha Levin
2011-05-26 6:42 ` [PATCH v2 7/8] kvm tools: Use dynamic IO port allocation in virtio-console Sasha Levin
2011-05-26 6:42 ` [PATCH v2 8/8] kvm tools: Use dynamic IO port allocation in virtio-net Sasha Levin
2011-05-26 8:53 ` [PATCH v2 1/8] kvm tools: Add optional parameter used in ioport callbacks Pekka Enberg
2011-05-26 9:02 ` Sasha Levin
2011-05-26 9:04 ` Pekka Enberg
2011-05-26 9:14 ` Sasha Levin
2011-05-26 9:20 ` Pekka Enberg
2011-05-26 9:38 ` Sasha Levin [this message]
2011-05-26 9:43 ` Pekka Enberg
2011-05-26 9:49 ` Pekka Enberg
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=1306402736.3065.14.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=asias.hejun@gmail.com \
--cc=gorcunov@gmail.com \
--cc=john@jfloren.net \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@kernel.org \
--cc=prasadjoshi124@gmail.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.