Michael S. Tsirkin wrote: > On Wed, Jan 06, 2010 at 05:19:45PM +0000, Jamie Lokier wrote: > > Michael S. Tsirkin wrote: > > > On Wed, Jan 06, 2010 at 09:24:45AM -0600, Anthony Liguori wrote: > > > > 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. > > > > I don't understand. What do you think would not work with > > helper="..." where ... is specified on the qemu command line by the > > management script, versus the management script doing the helper > > operations itself first and then calling qemu with fd=? > > > > If you are thinking that management scripts will tailor the -net > > arguments according to qemu version, you're right for some > > configurations (but not well established simple ones). > > > > Presumably management can do the same capability when specifying "..." > > - the difference being it would query the helper tool to get _it's_ > > features in some cases, e.g. for arguments to a helper which uses SSH > > to provide an encrypted tunnel. > > What won't work is that besides fd= management specifies many other > arguments to the -net flag.
I still don't understand. What prevents management from specifying the other arguments with helper=, either in the helper argument (for arguments to the helper itself), or to qemu (for things qemu needs be told)? > What you describe: helper= instead of fd= will work and I have no issue > with this. And we won't need any protocol between helper and qemu: just > the fd returned. You may still need qemu to know whether to use send/recv (datagram socket) or read/write with framing (pipe or something), but if it comes to that, qemu can use fstat() to decide what it needs. There is probably no need for options passed back, I agree :-) I think there is a lot to be said for letting the helper keep the initial unix socket open, so it can reliably detect when the parent qemu dies and then clean up. > But of course this means that it can't be used to create new > backends such as vepa, which often need to setup the fd in complex > ways. For vepa, I don't know if you mean the fd needs complex setup initially, or complex options with each packet. (Web browser unavailable right now). For complex initial setup, that's exactly what a helper would be good for. Any options needed for that setup would be part of the helper="/path/to/helper opts..." string. If there are options which depend on helper version, management can query the helper itself with /path/to/helper --help; that doesn't seem likely to be needed much. If individual packet transmission requires "complex ways" then of course that would have to be inside qemu. Is that the case with vepa and other things under discussion? I got the impression there isn't much variation in the way packets are tranmitted and received. -- Jamie
