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

[Anthony Liguori <anthony@codemonkey.ws>]

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<vilanova@ac.upc.edu>
>
>> This whole series:
>
>> Nacked-by: Anthony Liguori<aliguori@us.ibm.com>
>
>> 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 QEMU.

> 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.

Regards,

Anthony Liguori

>
>
> Lluis
>