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
