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, 10 Jun 2009 18:48:06 +0300 [thread overview]
Message-ID: <20090610154806.GF28601@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.
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.
>
> >
> > > + 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?
>
> - 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?
>
>
> >
> > >
> > > /* 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
next prev parent reply other threads:[~2009-06-10 15:51 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 [this message]
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=20090610154806.GF28601@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).