Re: [Qemu-devel] Re: Killing KQEMU

[Rick Vernam <rickv@hobi.com>]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 2826 bytes --]