[Top][All Lists]
[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.