On 07/10/2009 08:06 PM, Anthony Liguori wrote:
BTW, this is one of the challenges of doing pulls. I did the pull and
then deleted every qemu-io patch in my queue since I assumed that
everything that should go in was part of hch's pull request. In
general, that's the only sane way to do pulls
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
Sorry, I'm not able to follow you here. What is currently queued and
what do you think should be queued? Can you provide links/commit hashes?
Currenly queued:
http://repo.or.cz/w/qemu/
On Fri, Jul 10, 2009 at 07:12:37PM +0200, Kevin Wolf wrote:
> Ok, that makes sense. Will you take care of it once the renaming patch
> is in or should I resend it then?
If Anthony prefers patches I'll stop doing the git trees and you'll
have to repost it. If we continue with the git trees I can a
> As pointed out before, it doesn't break anything but adds a workaround
> for scenarios which are _now_ broken (16/32 bit target code exported as
> 64 bit is widely useless for gdb today). Sorry, but you never explained
> to me how user are _currently_ supposed to debug under that conditions,
> na
On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
> Sorry, I'm not able to follow you here. What is currently queued and
> what do you think should be queued? Can you provide links/commit hashes?
Currenly queued:
http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;
Paul Brook wrote:
> The 32/64-bit switching is just plain wrong, and makes it absolutely
> impossible for a client debugger to work correctly.
As pointed out before, it doesn't break anything but adds a workaround
for scenarios which are _now_ broken (16/32 bit target code exported as
64 bit is w
Paul Brook wrote:
Right, that part I'm okay with. But the vCont based gdb model presumes
a unified address space which while usually true for kernel address
spaces, isn't universally true and certainly not true when PC is in
userspace. That's what I understood to be the major objection to vCont
> Right, that part I'm okay with. But the vCont based gdb model presumes
> a unified address space which while usually true for kernel address
> spaces, isn't universally true and certainly not true when PC is in
> userspace. That's what I understood to be the major objection to vCont.
The threa
Kevin Wolf wrote:
Last time you said you don't want to get pull requests but rather
patches on the list.
I'm clearly trying to purposefully confuse you :-)
Honestly, I'm just trying to work with people. I saw the pull request,
so I pulled it. I would have been just as happy pulling in the
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
If I'm not mistaken, the patch "qemu-io: Implement
bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
expecting qe
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> That's nothing those patches changes (it's our current and only
>> debugging model for SMP until gdb provides a complete solution).
>>
>
> It Paul agrees, I'll pull it. But my understanding from the previous
> threads and posts was that Paul did no
Christoph Hellwig schrieb:
> On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
>>> If I'm not mistaken, the patch "qemu-io: Implement
>>> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>>>
>> I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
>> exp
Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> Anthony Liguori schrieb:
>>
>>> Jan Kiszka wrote:
>>>
Hmm, I must have missed this: Where is your staging tree hosted?
>>> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
>>> to move it to git
On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
> >If I'm not mistaken, the patch "qemu-io: Implement
> >bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
> >
>
> I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
> expecting qemu-io patches to go t
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm not mistaken,
Jan Kiszka wrote:
Something went wrong during transmission, and I missed that. Just sent
out those two as well.
Thanks, it's now all in staging.
That's nothing those patches changes (it's our current and only
debugging model for SMP until gdb provides a complete solution).
It Paul agr
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm not mistaken,
Anthony Liguori schrieb:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>
>
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
> to move it to git.qemu.org in the next few days.
If I'm not mistaken, the patch "qemu-io: Implemen
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Ah, thanks.
>>
>> OK, then I would like to know the status of my -boot patch queue [1]
>
> I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my
> inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are
> bios patches
Jan Kiszka wrote:
Ah, thanks.
OK, then I would like to know the status of my -boot patch queue [1]
I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my
inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are
bios patches. Did you have a numbering issue or
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>
>
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
> to move it to git.qemu.org in the next few days.
Ah, thanks.
OK, then I would like to know the statu
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscr
Anthony Liguori wrote:
> Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>> Any hope that -device can make the cut?
>>
> I've got most of the outstanding patches in staging now. The only thing
> missing is the PIIX refactoring from Isaku which I suspect is going to
> fuzz badly. -devic
Markus Armbruster wrote:
Anthony Liguori writes:
Any hope that -device can make the cut?
I've got most of the outstanding patches in staging now. The only thing
missing is the PIIX refactoring from Isaku which I suspect is going to
fuzz badly. -device is there.
I'll be testing this tod
Anthony Liguori writes:
> Mark McLoughlin wrote:
>> Hi Anthony,
>>
>> On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
>>
>>> Hi,
>>>
>>> It's getting to be about the time to start thinking about the
>>> 0.11.0 release. 0.10.0 was released on March 2nd so following with
>>> the 6 mon
Mark McLoughlin wrote:
Hi Anthony,
On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6 month
release cycle, that would put 0.11.0 at September
Hi Anthony,
On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
> Hi,
>
> It's getting to be about the time to start thinking about the 0.11.0
> release. 0.10.0 was released on March 2nd so following with the 6 month
> release cycle, that would put 0.11.0 at September 2nd.
>
> Based on
On 06/23/2009 06:09 PM, Blue Swirl wrote:
I think this is great, but OpenBIOS still uses Subversion. Can git use
SVN submodules for example?
No, but we could have a git svn mirror and include that.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
Blue Swirl wrote:
On 6/23/09, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6 month
release cycle, that would put 0.11.0 at September 2nd.
Based on the experiences with the
On 6/23/09, Anthony Liguori wrote:
> Hi,
>
> It's getting to be about the time to start thinking about the 0.11.0
> release. 0.10.0 was released on March 2nd so following with the 6 month
> release cycle, that would put 0.11.0 at September 2nd.
>
> Based on the experiences with the stable relea
On 06/23/2009 02:57 AM, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6
month release cycle, that would put 0.11.0 at September 2nd.
Based on the experiences with the stable rel
31 matches
Mail list logo
