[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: Planning for 0.13
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] Re: Planning for 0.13 |
Date: |
Wed, 6 Jan 2010 17:41:34 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
- [Qemu-devel] Re: Planning for 0.13, (continued)
- [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/05
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/05
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13,
Michael S. Tsirkin <=
- Re: [Qemu-devel] Re: Planning for 0.13, Jamie Lokier, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Jamie Lokier, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Paolo Bonzini, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Paolo Bonzini, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Jamie Lokier, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06