[Qemu-devel] Re: [PATCH] remove pieces of source code

[Jan Kiszka <jan.kiszka@web.de>]

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

Andreas Färber wrote:
> 
> Am 29.05.2009 um 20:49 schrieb Glauber Costa:
> 
>> On Fri, May 29, 2009 at 08:43:09AM -0700, Consul wrote:
>>> Glauber Costa wrote:
>>>> But traffic in the mailing list indicates that it is less and less
>>>> the case.
>>>> And more importantly: As it bitrots, nobody fixes it. so...
>>>>
>>>>> o There is no alternative for non-Linux users and folks with
>>>>> non-VT/SVM
>>>>> hardware
>>>>
>>>> Sure, but I don't think kqemu is such an alternative. ;-)
>>>
>>> It is. Without kqemu I'll have no alternative, but switch to VBox or
>>> VMWare.
>>> And none of them work with qcow images.
>> I'm not saying that because of any kind of functionality. I'm saying
>> it is
>> not an alternative, because nobody really maintains it.
> 
> KVM is no alternative either for us because nobody really maintains
> documentation of what interface and functionality we'd have to implement
> on Solaris, Windows, Mac OS X etc. where no KVM is available today.
> 
> I'd expect some documentation here:
> http://www.linux-kvm.org/page/Documents -- but no luck. No "Porting KVM
> For Dummies". ;(

There was and likely will never be any documentation for kqemu either.
But having worked on both, I can say that kvm is by an order of
magnitude easier to understand from its sources than kqemu.

Sorry, but if you are really interested in such a port, having to dig
through source code and ask questions to the community if something
remains unclear should not be the actual problem.

I've once ported the whole Linux IrDA stack to Windows (as its own stack
just sucked). There was no real design document at that point too, but
well structured code and a very responsive community  - which as quite
happy about patches against bugs I found running it "on the evil side".

> 
> I see no problem dumping kqemu support once KVM is available on the
> kqemu platforms, but now is really a bad point in time.

Take it the other way around: This (yet only discussed!) step comes with
the chance to trigger such a development.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]