qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mark McLoughlin <markmc@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Thu, 16 Apr 2009 15:49:57 +0100	[thread overview]
Message-ID: <1239893397.6860.190.camel@blaa> (raw)
In-Reply-To: <20090416010725.GA24264@amt.cnet>

Hi Marcelo,

On Wed, 2009-04-15 at 22:07 -0300, Marcelo Tosatti wrote:
> On Wed, Apr 15, 2009 at 07:34:21PM +0200, Jan Kiszka wrote:
> > Mark McLoughlin wrote:
> > > @@ -1095,12 +1095,12 @@ pci_e1000_init(PCIBus *bus, NICInfo *nd, int devfn)
> > >  
> > >      d->vc = qemu_new_vlan_client(nd->vlan, nd->model, nd->name,
> > >                                   e1000_receive, e1000_can_receive, d);
> > > +    d->vc->cleanup = e1000_cleanup;
> > 
> > Just to leave my comment here as well :) : I still consider this an
> > important, mostly required callback that should be lifted into
> > qemu_new_vlan_client(). That way, everyone who thinks (s)he doesn't need
> > it will have to explicitly null'ify it.
> 
> Agreed.

Oi! You're the one that introduced this:

    d->dev.unregister = pci_e1000_uninit;

which is basically the same thing. But ... "whatever" :-)

> > >      d->vc->link_status_changed = e1000_set_link_status;
> > >  
> > >      qemu_format_nic_info_str(d->vc, nd->macaddr);
> > >  
> > >      register_savevm(info_str, -1, 2, nic_save, nic_load, d);
> > > -    d->dev.unregister = pci_e1000_uninit;
> 
> I'm unsure about the fact that you consider device dependant details
> such as MMIO addresses part of the "VLANClient" abstraction. Don't 
> they belong to the PCI device, and as such, should be unregistered
> in (PCIDevice *)->unregister?
> 
> > > +static void mcf_fec_cleanup(VLANClientState *vc)
> > > +{
> > > +    mcf_fec_state *s = vc->opaque;
> > > +
> > > +    cpu_unregister_io_memory(s->mmio_index);
> > > +
> > > +    qemu_free(s);
> > > +}
> 
> Also the fact that you free the device structure in the non-PCI
> functions, but you don't in the PCI functions (because generic PCI
> code does it) is somewhat confusing.
> 
> Hum, I think abstracting away ISA devices would be a good thing.
> 
...
> > > +static void ne2000_cleanup(VLANClientState *vc)
> > > +{
> > > +    NE2000State *s = vc->opaque;
> > > +
> > > +    unregister_savevm("ne2000", s);
> > > +}
> 
> So unregister_savevm is common to all buses for the ne2000 chip, but
> isa_unassign_ioport is not. So what about moving non-device specific
> details to (VLANClientState *)->cleanup, and device specific to
> (XXXDevice *)->unregister?
> 
> For example there was symmetry between lsi_scsi_unregister and
> e1000_unregister before.
> 
> This would make the purpose of the interface you are creating clearer,
> IMHO.

I see where you're coming from, especially with the symmetry with block
devices.

However, the way I see it is that the VLANClientState should "own" the
PCIDevice, not the other way around - e.g. you want to free the device,
you should do qemu_del_vlan_client(), rather than
pci_device_unregister(). 

What follows from that is VLANClientState::cleanup() should call
pci_device_unregister().

If we did it the other way, then PCIDevice::unregister() should do
qemu_del_vlan_client() and callers should never free a PCI NIC directly
using del_vlan_client(), but instead call pci_device_unregister().

Futhermore, if we took the latter approach, we'd need a similar
abstraction to PCIDevice for the non-PCI NICs.

As for splitting the cleanups non-device specific and device specific
parts ... for most devices, no such separation exists. We mix all the
state up in the structure, and it's all allocated in the one place, so
separating out the cleanup seems a bit arbitrary.

Following up with an updated version of the patch which uses
PCIDevice::unregister() for unregister I/O memory and
VLANClientState::cleanup() for cleaning everything else up.

It's not perfect, by any means ... but it's a baby step in the right
direction IMHO.

Cheers,
Mark.

  parent reply	other threads:[~2009-04-16 14:50 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-15 16:29 [Qemu-devel] [PATCH 0/9] Misc networking fixes Mark McLoughlin
2009-04-15 16:29 ` [Qemu-devel] [PATCH 1/9] Remove stray GSO code from virtio_net Mark McLoughlin
2009-04-15 16:29   ` [Qemu-devel] [PATCH 2/9] struct iovec is now universally available Mark McLoughlin
2009-04-15 16:29     ` [Qemu-devel] [PATCH 3/9] Fix error handling in net_client_init() Mark McLoughlin
2009-04-15 16:29       ` [Qemu-devel] [PATCH 4/9] Don't fail PCI hotplug if no NIC model is supplied Mark McLoughlin
2009-04-15 16:29         ` [Qemu-devel] [PATCH 5/9] Remove some useless malloc() checking Mark McLoughlin
2009-04-15 16:29           ` [Qemu-devel] [PATCH 6/9] Remove NICInfo from e1000 and mipsnet state Mark McLoughlin
2009-04-15 16:29             ` [Qemu-devel] [PATCH 7/9] Add unregister_savevm() Mark McLoughlin
2009-04-15 16:29               ` [Qemu-devel] [PATCH 8/9] Use NICInfo::model for eepro100 savevm ID string Mark McLoughlin
2009-04-15 16:29                 ` [Qemu-devel] [PATCH 9/9] Introduce VLANClientState::cleanup() Mark McLoughlin
2009-04-15 17:34                   ` [Qemu-devel] " Jan Kiszka
2009-04-16  1:07                     ` Marcelo Tosatti
2009-04-16  3:24                       ` M. Warner Losh
2009-04-16 14:49                       ` Mark McLoughlin [this message]
2009-04-16 14:52                         ` [Qemu-devel] [PATCH 09/09 v2] " Mark McLoughlin
2009-04-16 14:53                           ` [Qemu-devel] [PATCH 10/09] Free VLANClientState using qemu_free() Mark McLoughlin
2009-04-16 20:44                         ` [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup() Marcelo Tosatti
2009-04-28 12:08                         ` Paul Brook
2009-04-28 16:46                           ` Anthony Liguori
2009-04-28 17:17                             ` Paul Brook
2009-04-28 17:25                               ` Anthony Liguori
2009-04-28 17:46                                 ` Paul Brook
2009-04-28 17:49                                   ` Anthony Liguori
2009-04-28 18:28                                     ` Paul Brook
2009-04-28 21:38                                       ` Anthony Liguori
2009-04-29 10:37                                         ` Paul Brook
2009-04-30 13:45                                           ` Avi Kivity
2009-04-30 16:02                                             ` Paul Brook
2009-04-30 16:20                                               ` Avi Kivity
2009-04-30 16:31                                                 ` Paul Brook
2009-04-30 16:32                                                   ` Avi Kivity
2009-04-30 16:37                                                     ` Anthony Liguori
2009-04-30 16:41                                                       ` Anthony Liguori
2009-04-30 16:58                                                         ` Paul Brook
2009-04-30 17:51                                                           ` Avi Kivity
2009-04-30 16:33                                                   ` Anthony Liguori
2009-04-30 16:32                                               ` Anthony Liguori
2009-04-30 16:57                                                 ` Blue Swirl
2009-04-30 17:11                                                   ` Anthony Liguori
2009-04-30 17:45                                                     ` Jan Kiszka
2009-04-30 17:48                                                       ` Avi Kivity
2009-04-30 18:17                                                         ` Jan Kiszka
2009-04-30 18:19                                                           ` Avi Kivity
2009-04-30 18:22                                                             ` Anthony Liguori
2009-04-30 17:59                                                       ` Anthony Liguori
2009-04-30 18:10                                                         ` Blue Swirl
2009-04-30 18:20                                                           ` Jan Kiszka
2009-04-30 18:32                                                           ` Anthony Liguori
2009-04-30 18:57                                                             ` Blue Swirl
2009-04-30 18:16                                                         ` Jan Kiszka
2009-04-29  7:36                             ` Markus Armbruster
2009-04-16 14:49                     ` Mark McLoughlin
2009-04-15 17:13           ` [Qemu-devel] Re: [PATCH 5/9] Remove some useless malloc() checking Jan Kiszka
2009-04-15 16:55     ` [Qemu-devel] [PATCH 2/9] struct iovec is now universally available Christoph Hellwig
2009-04-15 17:25       ` Mark McLoughlin
2009-04-15 17:27         ` Christoph Hellwig
2009-04-15 21:18         ` François Revol
2009-04-15 21:52           ` M. Warner Losh
2009-04-15 17:44       ` M. Warner Losh
2009-04-17 18:06   ` [Qemu-devel] [PATCH 1/9] Remove stray GSO code from virtio_net Anthony Liguori

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=1239893397.6860.190.camel@blaa \
    --to=markmc@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).