A slow week, with lots of bugfixes and some long term strategy discussions (such as talk of migrating the repository off of CVS), but the senior developers were mostly tied up digesting, debugging, and developing TCG, so most other qemu work wound up on the back burner.
A few older things were resubmitted or merged.
Alexander Graf posted:
supporting Mac OS X on Intel has been a long standing issue. The Q project has done a fabulous job maintaining patches that make things work for i386 Mac OS X, but do invasive changes to qemu internals. This set of patches attempts to make Mac OS X host support as compatible as possible to the existing Linux host and PowerPC Mac OS X support. Of course this means, that as long as Linux gcc4 support is broken, it won't work on Mac OS X either. Nevertheless all changes necessary to support the binary format (Mach-O) and several other minor issues that are Mac specific can be easily added to the existing code base without harming other platforms. This way people who want to run qemu on Mac OS X only have to maintain gcc4 patches and no Apple specific ones. This is version 2 of the patchset, adding support for and removing parts made obsolete by TCG.
There was no immediate discussion on the list.
Your humble editor forwarded a thread from linux-kernel:
On Tuesday 05 February 2008 15:07:27 H. Peter Anvin wrote: > Rob Landley wrote: > > When running a 2.6.24 kernel built for x86-64 under qemu via serial > > console, doing CPU-intensive things that also produce a lot of output > > (such as compiling software) tends to produce the error message in the > > title. > > > > Anybody have a clue why? It doesn't seem to cause an actual problem, but > > it's kind of annoying. > > > > (If it's a qemu issue, I can go bother them. It's possible that qemu > > isn't delivering interrupts as often as it expects, since that's limited > > by the granularity of the host timer; I know the clock in qemu can run a > > bit slow because it only gets clock interrupts when the host system isn't > > too busy to schedule the emulator. But this doesn't usually cause a > > problem. I _think_ the message is just a "this should never happen" type > > warning, which is happening to me. But I break stuff. :) > > This is because Qemu spews data to the serial port without any rate > limiting; this causes the in-kernel serial port driver to think the port > is stuck. The serial port emulation needs to make it possible to drain > the virtual FIFO every now and then, as opposed to filling it again > immediately. > > -hpa
This was followed a few days later by a patch from Peter Anvin, which implemented rate limiting in qemu's serial emulation to avoid flooding the kernel.
Blue Swirl pointed out a previously rejected rate limiting patch, and suggested that this could be genericized to apply to other devices. Both Peter and Paul Brook raised technical objections, pointing out that simulating FIFO exhaustion so interrupts return after doing a finite amount of work is not the same as rate limiting.
Your editor started this thread with a question about some remnants of code that had been removed, but it quickly evolved into a discussion of source control. Specifically:
Any news on the possible cvs->svn migration? I'd submit a cleanup patch to rip out the remaining traces of code_copy_enabled, but the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days so I'm not actually sure it's still there in cvs. Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there either...
Xen developer Ian Jackson declared that he considered such a migration to be a bad idea [ed: which made its eventual adoption almost inevitable]. Paul Brook replied
> To be perfectly honest, IMO there is little point moving an existing > project from CVS to SVN. I disagree. CVS has several fairly fundamental flaws (no global revision IDs, unable to move files, and more subtle problems with branches/tags). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. I'm sure advocates of each system will claim that their system is the "best", but I remain unconvinced. SVN may not have the bells and whistles of some of the more exotic systems. However it is is well tested proven technology, and IMO universally better than CVS.
And M. Warner Losh and Julian Seward elaborated
< FreeBSD is moving from CVS to SVN for these reasons. Just to second "M. Warner Losh": we moved Valgrind from CVS to SVN about 3.5 years ago and it was an excellent thing to do. It is not true to say there is no advantage over CVS -- the global revision IDs, the ability to rename files, and a simpler branching/tagging model are all big advantages. And the fact that it is more-or-less conceptually a drop-in replacement makes it easy for people to make the migration. Sure, Valgrind is a tiny project compared to FreeBSD. But we gain those advantages nonetheless.
(Note that at the time of this discussion, Savannah (the sourceforge clone that hosts qemu) supported SVN, but not git or hg.)
The thread spawned a second thread comparing various repository formats.
Anthony Liguori posted a proposal to allow QEMU's VNC servers to advertise itself via DNS extensions. There was no discussion on the list.
andrzej zaborowski suggested a cleanup of the RTC hardware emulation code. There was no discussion on the list.
Alexander Graf had some interesting suggestions for using qemu's built in gdb support to debug code that caused qemu to crash.
SVN 3976 introduced an -ncurses command line option, to display the client's vga text on the host via ncurses. Otherwise mostly bugfixes, optimizations, and upgrades of existing hardware types.