On 07/23/2012 03:40 PM, Eric Blake wrote: > On 07/23/2012 01:14 PM, Laine Stump wrote: >> On 07/23/2012 10:26 AM, Hendrik Schwartke wrote: >>> I'm currently working on a feature that dumps the network traffic of a >>> virtual interface over the streaming api of libvirt. >>> The goal is to offer the possiblity to debug network related problems of >>> guests without the need to have access to a shell on the host. >>> E.g. "virsh iface-dumptraffic virbr0 icmp | tcpdump -n -r -" prints all >>> icmp traffic on virbr0 to stdout. >>> The code below is only a proof of concept, but it should be possible to >>> recognize what I have in mind and how I want to implement it. >>> >>> So I would appreciate any comments on that! >>> >> It's definitely interesting functionality, but putting it in >> netcf_driver.c doesn't seem like the right place, since it doesn't use >> any netcf functionality, and could just as easily be made to work >> without it. On the other hand, since (the way you've implemented it) it >> is related to host interfaces, it kind of makes logical sense for it to >> be named virInterface<something>, and the backend of all those commands >> is currently in netcf_driver.c. > Then again, I have a patch that I need to revive and post a v2, which > renames things to use interface_driver instead of netcf_driver... > > https://www.redhat.com/archives/libvir-list/2012-June/msg01331.html
That patch came in while I was on vacation, so I only went as far as scanning it and marking it in red to read later), but not everything should just be changed from netcf to interface. The two concepts are related but separate. Practically speak, currently with_netcf == with_interface, but in reality it should be possible to have with_interface but not with_netcf - using "interface" in the name doesn't resolve the problem. Hmm. Looks like danpb's response to you exactly gets at the root of the problem: On 06/29/2012 12:32 PM, Daniel P. Berrange wrote: > I'm not a fan of this, because you are too tightly associating use of > the netcf library, with use of the interface drivers, and also > presuming a 1-1 relationship between a logical driver, and an external > library. THis breaks down if a module like the inteface driver needs > to check for multiple external libraries, and if the external > libraries are used by multiple different areas of the libvirt code. (he even anticipate the possibility that an "interface" driver might want to pull from two different sources for its functionality :-) So I assume you would respin based on those comments. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
