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: Wed, 3 Jun 2009 10:22:39 +0300	[thread overview]
Message-ID: <20090603072239.GB8134@redhat.com> (raw)
In-Reply-To: <20090603023108.GJ9176%yamahata@valinux.co.jp>

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.
> 
> > 
> > > +    pci_config_written_t callback;
> > > +};
> > >  
> > >  struct PCIDevice {
> > >      DeviceState qdev;
> > >      /* PCI config space */
> > >      uint8_t config[PCI_CONFIG_SPACE_SIZE];
> > > -
> > > -    /* Used to implement R/W bytes */
> > > -    uint8_t mask[PCI_CONFIG_SPACE_SIZE];
> > > +    struct PCIConfigReg config_regs[PCI_CONFIG_SPACE_SIZE];
> > 
> > I still think separate mask/config/callback arrays
> > are better - they are easier for devices to use. E.g. a single memset
> > can make a range of register writeable, and a single function call
> > does everything necessary to save a range the whole config space.
> > 
> > Add a callback array if you like, and be done with it.
> 
> Hmm, I don't think so. Maybe it's a matter of taste.
> Looking at your MSI/MSI-X patches, our patch series conflict with
> each other. That's bad. Let's resolve the conflicts.
> 
> - mask v.s. wmask
>   I think mask is ambiguous because which bits it represents,
>   writable bits or read only bits. 
>   let's rename it to common name.
>   wmask, w_mask, wr_mask, writable_mask or something like that.
>   What name do you prefer?

Not terribly important. I guess I like wmask if you let me pick.

> - array v.s. struct
>   I suppose this conflicts with you.
>   So after renaming, I'll make wmask into uint8_t wmask[]
>   (or whatever name we choose)
> 
> Then, we can avoid stepping on each other.
> What do you think?

Agreed. So what I need to do is rename mask into wmask, is that right?

> 
> > 
> > >  
> > >      /* the following fields are read only */
> > >      PCIBus *bus;
> > > @@ -180,6 +261,21 @@ struct PCIDevice {
> > >      int irq_state[4];
> > >  };
> > >  
> > > +typedef void(*pci_conf_init_t)(struct PCIConfigReg*);
> > > +
> > > +void pci_conf_initb(struct PCIConfigReg *config_regs, uint32_t addr,
> > > +                    pci_config_written_t callback, uint32_t wmask);
> > > +void pci_conf_initw(struct PCIConfigReg *config_regs, uint32_t addr,
> > > +                    pci_config_written_t callback, uint32_t wmask);
> > > +void pci_conf_initl(struct PCIConfigReg *config_regs, uint32_t addr,
> > > +                    pci_config_written_t callback, uint32_t wmask);
> > 
> > If we got rid of reg_offset, I think we won't need these.
> > We'd just do dev->callback[REGISTER] = my_callback.
> > 
> > 
> 
> -- 
> yamahata

-- 
MST

  reply	other threads:[~2009-06-03  7:25 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 [this message]
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
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=20090603072239.GB8134@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.