From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSY3r-0005Q3-Nu for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:44:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSY3n-0005NJ-U5 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:44:39 -0500 Received: from [199.232.76.173] (port=55415 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSY3n-0005N7-M5 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:44:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51125) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSY3n-0003yM-5t for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:44:35 -0500 Date: Wed, 6 Jan 2010 17:41:34 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Planning for 0.13 Message-ID: <20100106154134.GC4001@redhat.com> References: <20100105213350.GC30921@redhat.com> <4B43DA17.8080001@codemonkey.ws> <20100106104903.GA2248@redhat.com> <4B4483CA.2030101@linux.vnet.ibm.com> <20100106132043.GC2248@redhat.com> <4B449162.9040107@linux.vnet.ibm.com> <20100106135527.GE2248@redhat.com> <4B44A7E6.5030300@linux.vnet.ibm.com> <20100106151658.GB4001@redhat.com> <4B44AB3D.4010209@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B44AB3D.4010209@linux.vnet.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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