From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D0TWv-0003wJ-3V for qemu-devel@nongnu.org; Sun, 13 Feb 2005 18:51:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D0TWg-0003s8-Px for qemu-devel@nongnu.org; Sun, 13 Feb 2005 18:51:44 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D0TWe-0003oS-Mf for qemu-devel@nongnu.org; Sun, 13 Feb 2005 18:51:40 -0500 Received: from [24.206.159.132] (helo=mx3.kw.tx.cebridge.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1D0T2K-00081P-KN for qemu-devel@nongnu.org; Sun, 13 Feb 2005 18:20:21 -0500 Message-ID: <000e01c51222$8f893890$254d21d1@computername> From: References: <20050213182734.GA29432@jbrown.mylinuxbox.org><001c01c51203$24d2e510$254d21d1@computername> <20050213220614.GA30662@jbrown.mylinuxbox.org> Subject: Re: [Qemu-devel] Plex86 and Qemu Date: Sun, 13 Feb 2005 17:20:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org From: "Jim C. Brown" > a) is taken care of by letting user space qemu use dynamic translation = on > ring 0 instructions (same as qemu + kqemu works now), and b) is taken = care of If I remember right (and I may not), one of the problems with Plex86 v1 = was the difficulty of catching all possible transistions, from areas = where it was safe to let the code run, to areas that had to be carefully = monitored. It sounds like your idea of letting qemu handle the ring 0 stuff is = going to have the same kind of problems. But, I could be wrong. I'm not that good of a programmer, and I = certainly am not familiar with emulator programming. >> Then that's still going to be extremely limited. Effecting probably = 95%+ of the potential users. >=20 > It will support the same series of users that kqemu does. Right. And that's still very limited. There has been a lot of excitement in the mailing list, but few have = bothered to mention that for most users, the kqemu stuff doesn't matter. = I suspect most of those people either got distracted by the license, or = just kept their mouth shut. >> I wouldn't call that "majority of potential users"... Maybe "many in = this mailing list", but that's not quite the same thing. >>=20 >> [grimace] >>=20 >> Oh well. >=20 > Feel free to port it to a Windows host then. I noticed that you didn't = complain I'm not that good of a programmer. I have never made any comments to = suggest that I was. > when kqemu was announced, despite the fact that it only supports linux = hosts. > Care to explain why? 1) I don't need a reason to not complain. 2) I don't need to *justify* not complaing. 3) The question is a little insulting. But, to answer it anyway... Fabrice mentioned long ago that his module would only work with Linux = hosts. I don't know why. Whether its his familiarity with Linux, or if = it's something that can only be done under Linux and not Windows. (I = have no idea how vmware & virtualPC do their stuff, or what method kqemu = uses.) So when he did finally release it, it was no surprise. I was already = resigned to the fact that it wasn't going to help me in the slightest. = And therefor I don't care what license it is released under. If it ever = works under Windows, then I'll care. When you announced your plans, I was hoping that it might be something = that I and 95% of the rest of the world could actually use. You weren't = clear in your original message, so I asked. Turns out I was wrong though. Since it's not going to help us, I have no further interest in your = project. Your project sounds like it falls into the exact same category as = qemu-fast and now kqemu... Mildly worth knowing they exist, but of no = practical value for me. No reason to get excited or upset.