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 releases, here's what I'd 
recommend:

 o On July 15th, fork master -> stable-0.11
 o Change version to 0.10.90
 o Release qemu-0.11.0-rc1
 o Release additional -rcN releases every 1-2 weeks
 o Introduce a new maintainer for stable-0.10 (via git pulls)
 o At least 1 week before release, hopefully we'll have the final -rcN 
that we can then declare 0.11.0.

I think we should really try hard to make these dates.  I only have a 
few things that I would like to see happen before forking stable-0.11.  
Namely:

 o Setup qemu.org infrastructure (git hosting, wiki)
 o Setup qemu bug tracker (see next mail)
 o Include all ROM source code in tree via git submodules.  This is a 
major headache for distributors and I think it's important to resolve 
before our next release.
 o Disable kqemu by default.  The intention is _not_ to remove kqemu 
support.  Enabling kqemu by default causes a few unpleasant side effects 
including errors if -m is greater than 1/2 of the host physical memory.

I don't expect the qdev conversion will be complete by 0.11.  I think we 
should try to get as much of the invasive changes as possible in to make 
stable-0.11 as maintainable as possible.  However, I think it would be a 
mistake to gate the release on qdev.

-- 
Regards,

Anthony Liguori

--

[ message continues ]

I'll release qemu-kvm-0.11.0-rc* in parallel so we can get feedback from 
kvm users as well.

-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]

Sounds OK. I think OpenBIOS releases should follow similar schedule,

I think this is great, but OpenBIOS still uses Subversion. Can git use
SVN submodules for example?
--

[ message continues ]

No, but it's not too hard to make svn->git bridges.

Regards,

Anthony Liguori


-- 
Regards,

Anthony Liguori

--

[ message continues ]

No, but we could have a git svn mirror and include that.

-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]

Hi Anthony,


Are you still planning on creating the 0.11 branch next week?

Cheers,
Mark.

--

[ message continues ]

That's the plan although I need to make sure that all outstanding 
patches have been given adequate review before hand.  I want to give any 
patch that has been posted so far a reasonable chance to make it into 
0.11.  If I can get through the backlog today, then we'll stay on 
schedule.  Either way, there will be plenty of warning on the ML and 
opportunity for people to make suggestions.

Regards,


--

[ message continues ]

Any hope that -device can make the cut?
--

[ message continues ]

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 today and I'll try to push it tomorrow.

I'm going to delay the 0.10.6 release to coincide with 0.11.0-rc1.  I 
think we're on track for 0.11.0-rc1 for next Wednesday.

Taking a look over staging would be helpful for anyone interested.

-- 
Regards,

Anthony Liguori

--

[ message continues ]

Hmm, I must have missed this: Where is your staging tree hosted?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--

[ message continues ]

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

--

[ message continues ]

Ah, thanks.

OK, then I would like to know the status of my -boot patch queue [1] and
at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting
for the factual proof that patch 4 is unneeded - my last arguments
remained unanswered).

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/46703
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/46314

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--

[ message continues ]

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 did some patches get 

Paul expressed objection in the past to the debugging model of treating 
vcpus as threads vs. treating them as processes.  I'm not qualified to 
appreciate the difference so I'm inclined to side with Paul.  Am I 
missing something there?

-- 
Regards,

Anthony Liguori

--

[ message continues ]

Something went wrong during transmission, and I missed that. Just sent

That's nothing those patches changes (it's our current and only
debugging model for SMP until gdb provides a complete solution).

The recent discussion went around how to deal with some other gdb
limitation: debugging targets that run in x86's 16/32 bit mode vs. the
target arch being advertised as 64 bit. Existing qemu code doesn't work
with existing gdb in this scenario, and the question was how to deal

I interpreted [1] as that the rest is OK for Paul.

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/46399

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--

[ message continues ]

It Paul agrees, I'll pull it.  But my understanding from the previous 
threads and posts was that Paul did not want to implement vCont even as 

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 

Paul, can you clarify?

-- 
Regards,

Anthony Liguori

--

[ message continues ]

We also need vCont for proper thread debugging in user mode emulation.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--

[ message continues ]

The thread bits are the wrong way to do things, but are probably relatively 
harmless for now. Expect me to remove them at the first available opportunity.

The 32/64-bit switching is just plain wrong, and makes it absolutely 
impossible for a client debugger to work correctly.
If you really can't be bothered fixing gdb (and you *really* should), then it 
should be some form of user switch that tells qemu to always report a 32-bit 
register set.

Paul
--

[ message continues ]

I'll queue 1-3 then and we'll leave 4 for post-0.11 debate.

Regards,

Anthony Liguori
--

[ message continues ]

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,


I could offer to add a monitor command so that one can additionally
set/override the register representation during runtime that way. I do
not see a use case for it based on all the scenarios I'm aware of or
personally ran through the last year, but if it helps acceptance.
However, only a command line switch locking down the mode would solve
just half of the real-world problems.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--

[ message continues ]

You're working around a gdb bug it in a way that means a fixed gdb can't 
possibly work.  IMO the cure is worse than the disease.  Changing the register 
set reported to gdb part way through a session will always break. There's no 
possible way for gdb to what state the target is going to be in until it 
actually queries it.

Paul
--

[ message continues ]

If I'm not mistaken, the patch "qemu-io: Implement
bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.

Kevin
--

[ message continues ]

I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
expecting qemu-io patches to go through his tree.

Regards,

Anthony Liguori
--

[ message continues ]

I hold that patch back for now as it will need a bit of work if
the ->bdrv_{get,put}_buffer renaming patch goes in.  Just looking at
the queue Anthony only has queued up the older non-renaming version.

Anthony was this an accident or do you dislike the renaming?

--

[ message continues ]

Ok, that makes sense. Will you take care of it once the renaming patch
is in or should I resend it then?

Kevin
--

[ message continues ]

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 adapt it.

--

[ message continues ]

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?

Regards,

Anthony Liguori
--

[ message continues ]

Currenly queued:

	http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;h=9ecf9f92d22f28eccf8a7682b18...

Updated version:

	http://marc.info/?l=qemu-devel&m=124706191805387&w=2

--

[ message continues ]

No Signed-off-by, not a top-level patch.  I removed the old one from the 
queue though and will add your new one once you resend.

No Signed-off-by is the killer though.  I cannot take a patch that 
doesn't have a Signed-off-by.

Regards,

Anthony Liguori

--

[ message continues ]

Last time you said you don't want to get pull requests but rather
patches on the list.

Christoph, would you be so kind to push the patch to your queue and fill
the pull request form for Anthony in three copies, signed and with
official stamp...?

Kevin
--

[ message continues ]

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 patches 

Don't forget to get it notarized after committee approval.

Regards,


--

[ message continues ]

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 so if someone requests a 
pull in the future, please make sure that you've gone through and pulled 
any patch from the list first.

-- 
Regards,

Anthony Liguori

--

[ message continues ]

Pulls and stale queues are incompatible.  So long as everything is in 
patches, it doesn't matter since duplicate patches won't apply.  However 
a branch can't be based on a queue (since that's liable to change any 
time), and the branch can't commit and patches in the queue (since the 
queue might be committed any time).  If you want to pull, you'll need to 
shorten your queues (that will improve many other people's quality of 
life, btw).


-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]