Re: [Qemu-devel] Re: Killing KQEMU

[Rick Vernam]

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