Re: [Qemu-devel] Re: Planning for 0.13

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 06, 2010 at 09:24:45AM -0600, Anthony Liguori wrote:
> On 01/06/2010 09:16 AM, Michael S. Tsirkin wrote:
>> How otherwise would scripts know how to talk to qemu?
>> Just just happens to match command line format you say?
>> And the way to discover what that format is ... how exactly?
>>
>> Look, yes we could split this stuff out but this is just maintainance
>> headache, each change in backend will now need to be done in multiple
>> places, we'll have to care about old scripts, new scripts, it's just a
>> mess and at the end we will get existing functionality back and codebase
>> which is harder to debug and develop.
>>    
>
> A helper is semantics equivalent to passing an fd from a management  
> tool.  All of the problems you describe are equally applicable to that  
> model.

No, because management calls qemu and parses qemu help output.  Yes it
is not ideal but it works today.

> The question is, should we take in code in qemu to support any possible  
> mechanism of creation of networking or should we just make sure their  
> all possible by passing in an appropriate fd.

We already do this. What will not work generally is *returning* fd from
helper. And IMO we are better off not pretending it's possible.

> Having helpers does not mean that we would have no backends built into  
> qemu.  It just means that's it's possible to create backends outside of  
> qemu.
> 
> Of course, we need to evalute whether a new backend should be in qemu or  
> outside of qemu but that's something to handle on a case-by-case basis.
>
> Regards,
>
> Anthony Liguori


To the point, I think we are better off with packet socket (vepa)
backend in qemu than as a helper script.

-- 
MST