Anthony Liguori <anthony@xxxxxxxxxxxxx> writes: > On 05/29/2012 04:14 PM, Markus Armbruster wrote: >> Luiz Capitulino<lcapitulino@xxxxxxxxxx> writes: >> >>> On Mon, 28 May 2012 12:17:04 +0100 >>> Stefan Hajnoczi<stefanha@xxxxxxxxxxxxxxxxxx> wrote: >>> >>>> What we need to decide is whether it's okay to drop QEMU "VLANs" >>>> completely and change dump command-line syntax? >>> >>> I'd vote for dropping it. >>> >>>> I think vlan-hub doesn't hurt anyone because the code has been isolated >>>> and we keep backwards compatibility. So I'd personally still go the >>>> vlan-hub route for QEMU 1.x. >>> >>> Just to make it clear: I'm not against this series. I'm against having >>> the functionality in qemu. If we want to keep the functionality, then I >>> completely agree that this series is the way to go. >> >> I agree with Luiz: if we want to reimplement that much of networking >> within QEMU, this series does it in a much better way than VLANs, but >> I'd rather not do it at all. >> >> Just advice, not a strong objection. > > Doesn't the same logic apply to reimplementing file systems? > Shouldn't we drop qcow3 in favor of using btrfs? btrfs isn't ready for production, so this is a hypothetical question. > It's easy to make the NIH argument when it's a feature you don't care about. > > A lot of people use vlans. It's the only way -net socket is useful > too. Just because most KVM/libvirt users don't doesn't mean they > aren't an important feature to preserve. I specifically asked for evidence on actual use of VLANs, and which uses of VLANs can't be readily upgraded to better-performing external solutions. You asserting it is used "a lot" isn't a full answer, but it's (slightly) better than nothing. > I would strongly nack any attempt to remove vlans w/o providing some > mechanism for backwards compatibility which is exactly what this patch > series does. Roma locuta, causa finita. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
