[Qemu-devel] qemu: tree for pci related fixes

[Qemu-devel] qemu: tree for pci related fixes

[Michael S. Tsirkin]

Hi!
I created a qemu tree to collect pci related qemu fixes,
to make sure they don't get lost.

The idea's the patches have been posted on list already, so it should be enough
to repost a short summary here, rather than flood everyone's
mailboxes by reposting a full patchset.

The tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci

Beware: do not publish a tree on top of this one as I might be rebasing it. If
you want me to add a patch there, just mail me.

Below's the first nag:

---

Here are the pci fixes I know of that haven't been applied already.
Anthony, all, any more comments on any of them?
If yes, please reply on the original patch.
If no, please apply.

9305505 qemu/virtio-pci: remove unnecessary check
c128c88 qemu/pci: reset device registers on bus reset
74b7e8b qemu/pci: refactor code/symbolic constants
5307502 qemu/virtio: fix reset with device removal
c1f2e99 qemu/qdev: type safety in reset handler

Thanks,

-- 
MST

[Qemu-devel] Re: qemu: tree for pci related fixes

[Anthony Liguori]

Hi Michael,

Michael S. Tsirkin wrote:
> Hi!
> I created a qemu tree to collect pci related qemu fixes,
> to make sure they don't get lost.
>
> The idea's the patches have been posted on list already, so it should be enough
> to repost a short summary here, rather than flood everyone's
> mailboxes by reposting a full patchset.
>
> The tree is here:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
>
> Beware: do not publish a tree on top of this one as I might be rebasing it. If
> you want me to add a patch there, just mail me.
>
> Below's the first nag:
>
> ---
>
> Here are the pci fixes I know of that haven't been applied already.
> Anthony, all, any more comments on any of them?
> If yes, please reply on the original patch.
> If no, please apply.
>
> 9305505 qemu/virtio-pci: remove unnecessary check
>   

This was posted yesterday.

> c128c88 qemu/pci: reset device registers on bus reset
> 74b7e8b qemu/pci: refactor code/symbolic constants
> 5307502 qemu/virtio: fix reset with device removal
> c1f2e99 qemu/qdev: type safety in reset handler
>   

These were posted a week ago.  I am behind on staging unfortunately.

I think it makes sense for everyone to keep their own trees and to make 
them publicly accessible.  However, for resends, I would still like them 
to occur on the mailing list.

In general, I would wait at least two weeks for a resend.  I understand 
that this is a very long time and I'm working on trying to make patch 
response time more reliable.  I would like to point out though that 
these patches are by no means lost.

Regards,

Anthony Liguori

[Qemu-devel] Re: qemu: tree for pci related fixes

[Michael S. Tsirkin]

On Wed, Sep 23, 2009 at 01:11:48PM -0500, Anthony Liguori wrote:
> I think it makes sense for everyone to keep their own trees and to make  
> them publicly accessible.  However, for resends, I would still like them  
> to occur on the mailing list.

Okay I guess .. but why?

[Qemu-devel] Re: qemu: tree for pci related fixes

[Anthony Liguori]

Michael S. Tsirkin wrote:
> On Wed, Sep 23, 2009 at 01:11:48PM -0500, Anthony Liguori wrote:
>   
>> I think it makes sense for everyone to keep their own trees and to make  
>> them publicly accessible.  However, for resends, I would still like them  
>> to occur on the mailing list.
>>     
>
> Okay I guess .. but why?
>   
Resends happen for one of two reasons.  Either I'm too slow and the 
sender is impatient or I've dropped the patch and not provided 
appropriate explanation.  I see both cases as a failure on my part and 
[RESEND] on the list gets my attention much better than having a git tree.

Regards,

Anthony Liguori

[Qemu-devel] Re: qemu: tree for pci related fixes

[Michael S. Tsirkin]

On Wed, Sep 23, 2009 at 03:38:37PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Wed, Sep 23, 2009 at 01:11:48PM -0500, Anthony Liguori wrote:
>>   
>>> I think it makes sense for everyone to keep their own trees and to 
>>> make  them publicly accessible.  However, for resends, I would still 
>>> like them  to occur on the mailing list.
>>>     
>>
>> Okay I guess .. but why?
>>   
> Resends happen for one of two reasons.  Either I'm too slow and the  
> sender is impatient or I've dropped the patch and not provided  
> appropriate explanation.  I see both cases as a failure on my part and  
> [RESEND] on the list gets my attention much better than having a git 
> tree.
>
> Regards,
>
> Anthony Liguori

OK, so the tree will complement RESENDs, not replace them.
Maybe I'll try to script something that converts old patches to RESENDs,
we'll see.

-- 
MST

[Qemu-devel] Re: qemu: tree for pci related fixes

[Avi Kivity]

On 09/24/2009 07:18 AM, Michael S. Tsirkin wrote:
> Maybe I'll try to script something that converts old patches to RESENDs,
> we'll see

Please don't.  Increasing pressure on an overloaded system will usually 
reduce throughput.  We need restraint, not automation.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: qemu: tree for pci related fixes

[Michael S. Tsirkin]

On Wed, Sep 23, 2009 at 01:11:48PM -0500, Anthony Liguori wrote:
> Hi Michael,
>
> Michael S. Tsirkin wrote:
>> Hi!
>> I created a qemu tree to collect pci related qemu fixes,
>> to make sure they don't get lost.
>>
>> The idea's the patches have been posted on list already, so it should be enough
>> to repost a short summary here, rather than flood everyone's
>> mailboxes by reposting a full patchset.
>>
>> The tree is here:
>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
>>
>> Beware: do not publish a tree on top of this one as I might be rebasing it. If
>> you want me to add a patch there, just mail me.
>>
>> Below's the first nag:
>>
>> ---
>>
>> Here are the pci fixes I know of that haven't been applied already.
>> Anthony, all, any more comments on any of them?
>> If yes, please reply on the original patch.
>> If no, please apply.
>>
>> 9305505 qemu/virtio-pci: remove unnecessary check
>>   
>
> This was posted yesterday.

Well, it's an obvious one-liner.  Trivial patches can get in
my tree faster than complex ones.  I realize you have a huge queue of patches
to go through so even trivial ones become a burden with
compilation failures and whatnot, but my queue is short :)

>> c128c88 qemu/pci: reset device registers on bus reset
>> 74b7e8b qemu/pci: refactor code/symbolic constants
>> 5307502 qemu/virtio: fix reset with device removal
>> c1f2e99 qemu/qdev: type safety in reset handler
>>   
>
> These were posted a week ago.  I am behind on staging unfortunately.
> 
> I think it makes sense for everyone to keep their own trees and to make  
> them publicly accessible.  However, for resends, I would still like them  
> to occur on the mailing list.
>
> In general, I would wait at least two weeks for a resend.  I understand  
> that this is a very long time and I'm working on trying to make patch  
> response time more reliable.  I would like to point out though that  
> these patches are by no means lost.

Yes, recently I do not remember real need for resends, as in patch being
lost.  That's why I'm sending out a summary instead.  For example, it is
possible that some objection to a patch was not addressed and the author
missed this fact in the latest version.  I'm not trying to say "merge
this now", I'm trying to say "I think it's ready, please shout if it's
not".

>
> Regards,
>
> Anthony Liguori