All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Glauber Costa <glommer@redhat.com>,
	qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] sending pci information over the wire
Date: Fri, 19 Jun 2009 16:33:42 +0200	[thread overview]
Message-ID: <4A3BA1C6.6040701@redhat.com> (raw)
In-Reply-To: <4A3B8E56.3040903@codemonkey.ws>

On 06/19/09 15:10, Anthony Liguori wrote:
> My plan for your qdev series is to give a little more time for feedback,
> then ask you to rebase/resubmit so they can be applied. Give it a couple
> more days to give people a chance to review.

Good.

>> Likewise devtree: Paul posted the patches, got a number of reviews
>> comments. No discussion of the concerns happened though. There is also
>> no activity in Pauls git tree.
>
> I think we're all just waiting for Paul to commit something.

Looking forward to that.

>> (1) How will we handle fdt and hotplug? We can keep the qdev tree
>> and the fdt in sync all the time. Or we generate a fresh fdt
>> from the qdev tree when needed (i.e. for savevm, migration and
>> maybe the ppc kernel).
>
> I'd lean toward the later.

It is probably easier to handle that way.

>> I really like to see some progress here, otherwise 2017 wouldn't be
>> just a running gag.
>
> I agree. Not every patch is reasonable to commit in 24 hours though.

Sure.  Especially large, non-trivial patches need some more time to 
review.  The oldest patches of the qdev series are out for more than a 
week now though.

The first one ("update pci device registration") is quite invasive and 
probably conflicts with everybody doing pci-related qdev work.  It also 
fixes the fundamental issue that the code in master right now can't 
handle pci devices which need config space access handlers.

> I think something
> we could do better is avoiding losing track of patches though. I'm
> working on that.

Related issues:  Looks like the qemu-commits list is lossy.  I havn't 
seen messages for my two most recent vnc patches.  I figured while 
rebasing the vnc patches because git surprised me with "nothing to do". 
  Also it seems for merges only a message for the merge commit goes to 
the list, not for the individual patches.

cheers,
   Gerd

  reply	other threads:[~2009-06-19 14:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 19:39 [Qemu-devel] sending pci information over the wire Glauber Costa
2009-06-18 20:03 ` Anthony Liguori
2009-06-18 20:12   ` Glauber Costa
2009-06-18 20:38     ` Anthony Liguori
2009-06-19  8:55       ` Gerd Hoffmann
2009-06-19 13:10         ` Anthony Liguori
2009-06-19 14:33           ` Gerd Hoffmann [this message]
2009-06-19 14:47             ` Paul Brook
2009-06-19 15:16             ` Anthony Liguori
2009-06-19 15:38               ` Gerd Hoffmann
2009-06-19 15:56                 ` Anthony Liguori
2009-06-20 18:58   ` Avi Kivity

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=4A3BA1C6.6040701@redhat.com \
    --to=kraxel@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=glommer@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 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.