From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MByIJ-00061P-1c for qemu-devel@nongnu.org; Wed, 03 Jun 2009 17:46:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MByID-0005y6-Gz for qemu-devel@nongnu.org; Wed, 03 Jun 2009 17:46:45 -0400 Received: from [199.232.76.173] (port=60395 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MByID-0005xf-96 for qemu-devel@nongnu.org; Wed, 03 Jun 2009 17:46:41 -0400 Received: from hobi.com ([130.94.185.247]:4244) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MByIC-0007aj-K5 for qemu-devel@nongnu.org; Wed, 03 Jun 2009 17:46:41 -0400 Received: from unknown (HELO ricklap.localnet) ([68.23.60.237]) (envelope-sender ) by 130.94.185.247 (qmail-ldap-1.03) with SMTP for ; 3 Jun 2009 21:46:38 -0000 From: Rick Vernam Subject: Re: [Qemu-devel] Re: Killing KQEMU Date: Wed, 3 Jun 2009 16:46:37 -0500 References: <20090602035217.GA16574@foursquare.net> <200906022130.42639.paul@codesourcery.com> <20090603213449.GA21824@foursquare.net> In-Reply-To: <20090603213449.GA21824@foursquare.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-00=_98uJKYxexXumdFa" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906031646.37598.rickv@hobi.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --Boundary-00=_98uJKYxexXumdFa Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 03 June 2009 4:34:49 pm Chris Frey wrote: > On Tue, Jun 02, 2009 at 09:30:42PM +0100, Paul Brook wrote: > > They're horrid hacks that I only reluctantly created in the first place. > > Limiting guest physical memory to 4G is a fairly serous issue. Requiring > > the user specify how much ram they require upfront will not be acceptable > > once we have machine config files. > > I see. Let me thank you then for adding those hacks. I'm a user > that truly appreciates it. > > > Sure, but this is actually part of my point. If noone cares enough to > > track+test the development branch, then it just proves how little anyone > > actually cares about kqemu. > > I do. I can't do it every day, but every so often I do a git fetch and > try it out. I can report that Fedora 10 hangs during boot using kqemu > 1.4.0pre1 and git 34aee2552fb5f4329d59a60f939656214b26d7f8 (0.10.4), > but that if I can coax it past the startup of services, it runs fine > after that. That coaxing is easier said than done, though, so I'm assuming > it is some kind of kqemu race. Unfortunately, I have no more data than > that, and not enough expertise yet to find out why. Likewise, I do the same. I have documented a few issues I've come across, but when I could no longer debug with my current level of experience I just dropped it. I just don't have the time to ascend the learning curve - another way of saying I don't care *enough* ... > > > [1] Unsupportable == I'm not letting it anywhere near my production > > systems. When it breaks you keep both pieces, and it's unlikely anyone > > knows how to glue them back together again. > > That's understandable. But for a developer like me, kqemu sure saves a lot > of time when it works. > > - Chris --Boundary-00=_98uJKYxexXumdFa Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 03 June 2009 4:34:49 pm Chris Frey wrote:
> On Tue, Jun 02, 2009 at 09:30:42PM +0100, Paul Brook wrote:
> > They're horrid hacks that I only reluctantly created in the first place.
> > Limiting guest physical memory to 4G is a fairly serous issue. Requiring
> > the user specify how much ram they require upfront will not be acceptable
> > once we have machine config files.
>
> I see. Let me thank you then for adding those hacks. I'm a user
> that truly appreciates it.
>
> > Sure, but this is actually part of my point. If noone cares enough to
> > track+test the development branch, then it just proves how little anyone
> > actually cares about kqemu.
>
> I do. I can't do it every day, but every so often I do a git fetch and
> try it out. I can report that Fedora 10 hangs during boot using kqemu
> 1.4.0pre1 and git 34aee2552fb5f4329d59a60f939656214b26d7f8 (0.10.4),
> but that if I can coax it past the startup of services, it runs fine
> after that. That coaxing is easier said than done, though, so I'm assuming
> it is some kind of kqemu race. Unfortunately, I have no more data than
> that, and not enough expertise yet to find out why.


Likewise, I do the same. I have documented a few issues I've come across, but when I could no longer debug with my current level of experience I just dropped it. I just don't have the time to ascend the learning curve - another way of saying I don't care *enough* ...


>
> > [1] Unsupportable == I'm not letting it anywhere near my production
> > systems. When it breaks you keep both pieces, and it's unlikely anyone
> > knows how to glue them back together again.
>
> That's understandable. But for a developer like me, kqemu sure saves a lot
> of time when it works.
>
> - Chris


--Boundary-00=_98uJKYxexXumdFa--