On Mon, Mar 21, 2011 at 5:53 PM, Brad <b...@comstyle.com> wrote: > On 22/03/11 4:54 PM, Stanley Lieber wrote: >>> >>> I've gotten one request to decommission qemu-old. B It surprised me, >>> as I thought there were still issues with qemu/ even with the semi recent >>> thread fix as well as performance differences. >>> >>> Does anybody have objection to retiring qemu-old to the attic or ? >>> >>> I'd rather not do this prematurely but if the time has come, this is the >>> right time of release cycle to do it. >> >> I'm probably less educated about the functionality of newer qemu than I >> should be, but I still use the old version from ports (along with kqemu) >> to host >> Plan 9 on various systems. My understanding is that moving to the newer >> version(s) of qemu would introduce a performance hit, since kqemu is >> deprecated >> and whatever newer, fancier kernel integration has been introduced is not >> yet >> supported on OpenBSD. >> >> Is this wildly off-base? > > KQEMU is an unsupported piece of code that no one has ever maintained, > doesn't work on MP kernels and has issues even on SP kernels. It's not > deprecated. It is plain dead, period. No one cared to actually fix it when > the QEMU developers asked on their list for the OS's that actually > used it (*BSD, Solaris) and later some of its design limitations prevented > further progress so support was removed all together. > > Taking that out of the picture and doing an apples to apples comparison can > you find any real issues between the versions of QEMU that have a real > effect on your Plan 9 images?
No experimental evidence, yet, but I'm willing to give it a shot. Subjectively, the old qemu feels quite a bit slower without kqemu. I'll do some testing. -sl
