qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Date: Mon, 04 Jun 2012 09:24:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 05/29/2012 04:14 PM, Markus Armbruster wrote:
>> Luiz Capitulino<address@hidden>  writes:
>>
>>> On Mon, 28 May 2012 12:17:04 +0100
>>> Stefan Hajnoczi<address@hidden>  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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]