All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.