From: "Michael S. Tsirkin" <mst@redhat.com>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: paul@codesourcery.com, mtosatti@redhat.com, avi@redhat.com,
qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] Re: [PATCH 3/7] pci: pci_default_config_write() clean up.
Date: Mon, 15 Jun 2009 13:42:38 +0300 [thread overview]
Message-ID: <20090615104238.GC6351@redhat.com> (raw)
In-Reply-To: <20090615091204.GE9418%yamahata@valinux.co.jp>
On Mon, Jun 15, 2009 at 06:12:04PM +0900, Isaku Yamahata wrote:
> On Wed, Jun 10, 2009 at 06:48:06PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 03, 2009 at 11:31:08AM +0900, Isaku Yamahata wrote:
> > > On Tue, Jun 02, 2009 at 01:01:21PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Jun 02, 2009 at 03:42:46PM +0900, Isaku Yamahata wrote:
> > > > > +struct PCIConfigReg {
> > > > > + uint8_t wmask;
> > > > > + /* offset of registers in bits for 2/4 bytes function register */
> > > > > + uint8_t reg_offset;
> > > >
> > > > Sorry about being dense, but the comment still doesn't help me much.
> > > > Can't we simply use the index in the array as offset?
> > >
> > > No. I believe this is helpfull.
> > > the next patch for hw/wdt_i6300esb.c is a good example.
> > > With this, we can replace fragile address and len comparison
> > > with one callback per one register function.
> > >
> > > For that, the member which represents the position in function
> > > is necessary.
> >
> > So maybe this is going too far into a table-driven direction then.
> > Tables are good for common case, exceptions are better handled
> > by regular functional design.
> >
> > I agree addr/len comparisons are fragile, but can't we simply implement
> > functions to encapsulate them? Along the lines of:
> >
> > static inline int offset_in_range(int offset, int address, int len)
> > {
> > return address <= offset && address + len > offset;
> > }
> >
> > static inline int ranges_match(int addr1, int len1,
> > int addr2, int len2)
> > {
> > return offset_affected(addr1, addr2, len2) ||
> > offset_affected(addr2, addr1, len1);
> > }
> >
> > Switching address and len comparison to use this would be a good cleanup
> > IMO.
>
> Introducing helper function sounds a good idea.
Should be a separate patch IMO.
> I suppose that reg_offset and related functions can be removed
> by helper functions.
> So new callback function type would be
>
> typedef void (*pci_config_written_t)(struct PCIDevice *d,
> uint32_t addr, uint32_t val, int len);
>
> Since this is same as PCIConfigWriteFunc, pci_config_written_t would
> be removed with the next version.
--
MST
next prev parent reply other threads:[~2009-06-15 10:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 6:42 [Qemu-devel] [PATCH 0/7] pci bridge clean up and multiple pci bus support v2 Isaku Yamahata
2009-06-02 6:42 ` [Qemu-devel] [PATCH 1/7] vmware_vga: clean up Isaku Yamahata
2009-06-10 15:08 ` [Qemu-devel] " Michael S. Tsirkin
2009-06-02 6:42 ` [Qemu-devel] [PATCH 2/7] qemu: make default_write_config use mask table Isaku Yamahata
2009-06-02 6:42 ` [Qemu-devel] [PATCH 3/7] pci: pci_default_config_write() clean up Isaku Yamahata
2009-06-02 10:01 ` [Qemu-devel] " Michael S. Tsirkin
2009-06-03 2:31 ` Isaku Yamahata
2009-06-03 7:22 ` Michael S. Tsirkin
2009-06-03 12:25 ` Isaku Yamahata
2009-06-05 10:43 ` Michael S. Tsirkin
2009-06-10 15:48 ` Michael S. Tsirkin
2009-06-15 9:12 ` Isaku Yamahata
2009-06-15 10:42 ` Michael S. Tsirkin [this message]
2009-06-02 6:42 ` [Qemu-devel] [PATCH 4/7] pci/config: convert pci configuration space handler to use callback Isaku Yamahata
2009-06-10 15:16 ` [Qemu-devel] " Michael S. Tsirkin
2009-06-02 6:42 ` [Qemu-devel] [PATCH 5/7] pci: PCIBus clean up Isaku Yamahata
2009-06-02 6:42 ` [Qemu-devel] [PATCH 6/7] pci/brdige qdevfy Isaku Yamahata
2009-06-02 6:42 ` [Qemu-devel] [PATCH 7/7] [RFC] pci bus: preliminary for multi pci bus support Isaku Yamahata
2009-06-02 7:13 ` [Qemu-devel] " Avi Kivity
2009-06-02 7:46 ` Isaku Yamahata
2009-06-02 8:51 ` Avi Kivity
2009-06-02 13:03 ` Markus Armbruster
2009-06-02 12:56 ` [Qemu-devel] " Markus Armbruster
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=20090615104238.GC6351@redhat.com \
--to=mst@redhat.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=mtosatti@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).