[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU back

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Date: Wed, 07 Dec 2011 07:55:10 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/07/2011 06:21 AM, Lluís Vilanova wrote:
Anthony Liguori writes:

On 12/05/2011 04:22 PM, Lluís Vilanova wrote:
Provides the ability for the guest to communicate with user-provided code inside
QEMU itself, using a lightweight mechanism.

See first commit for a full description.

Signed-off-by: Lluís Vilanova<address@hidden>

This whole series:

Nacked-by: Anthony Liguori<address@hidden>

If you want to extend QEMU, then send proper patches.  Adding random C files to
the build is unacceptable.

What do you mean by proper patches?

If you want to add "custom functionality" to QEMU, send a patch to upstream 

The whole point of this is to ease the
process for the user to add custom guest-to-qemu interactions, so there is no
"proper implementation" here.

That's too vague as far as I'm concerned. The only reason I can see to have a mechanism like this is 1) to avoid pushing stuff upstream and/or 2) to circumvent QEMU licensing by shipping a separate file that the user includes themselves.

I see no reason to encourage either of these things. It also creates an inevitable problem of internal API stability. What happens when the tree changes and all of these "custom guest-to-qemu interactions" break?

You may claim that it's an unsupported interface, but what will actually happen is that users will start depending on these custom features long after the initial developer has stopped caring.

Blue Swirl already mentioned this can be used for testing qemu itself, while my
use case is coupled with the trace instrumentation features (I'll probably send
the first batch today).

In terms of supporting this mechanism, all backend code needs to live in upstream QEMU. That's a hard requirement. No configure flags to pull in random C files and no dlopens.

If you resent the series doing that, it'd be more likely to be merged but since I don't think your intention is to push backend code into QEMU, I wonder whether it's worth really merging this mechanism at all.

If this is just infrastructure that is only used by private forks, I don't think it belongs upstream.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]