qemu-old .. relevent or not?
I've gotten one request to decommission qemu-old. 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. Thanks, -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: qemu-old .. relevent or not?
I've gotten one request to decommission qemu-old. 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? -sl
Re: qemu-old .. relevent or not?
* Todd T. Fries t...@fries.net [2011-03-21 22:01]: Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 yet and due to this situation it'll be a bit, but the previous 0.13.something was oh so much worse than 0.9.x. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: qemu-old .. relevent or not?
I withdraw any thoughts of removing qemu-old anytime soon based on feedback. Henning confirms performance gains for keeping it. And we have a reminder that while kqemu is not recommended, it is only usable on qemu-old. Penned by Todd T. Fries on 20110321 15:58.35, we have: | I've gotten one request to decommission qemu-old. 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. | | Thanks, | -- | Todd Fries .. t...@fries.net | | _ | | \ 1.636.410.0632 (voice) | | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | | ..in support of free software solutions. \ sip:4052279...@ekiga.net | \\ | | 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A | http://todd.fries.net/pgp.txt -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: qemu-old .. relevent or not?
On 21/03/11 5:59 PM, Henning Brauer wrote: * Todd T. Friest...@fries.net [2011-03-21 22:01]: Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 yet and due to this situation it'll be a bit, but the previous 0.13.something was oh so much worse than 0.9.x. Ok, well when you get your laptops back provide real bug report(s). For all I know oh so much worse was due to the libpthread bug which was causing the crashing of QEMU and/or hosted OS's within QEMU. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: qemu-old .. relevent or not?
On 21/03/11 7:08 PM, Stanley Lieber wrote: On Mon, Mar 21, 2011 at 5:53 PM, Bradb...@comstyle.com wrote: On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. 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. Of course. That's an apples to oranges comparison. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: qemu-old .. relevent or not?
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
