From: Anthony Liguori <anthony@codemonkey.ws>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
Date: Tue, 08 Jun 2010 08:03:33 -0500 [thread overview]
Message-ID: <4C0E3FA5.9060905@codemonkey.ws> (raw)
In-Reply-To: <20100608121351.GA21380@redhat.com>
On 06/08/2010 07:13 AM, Michael S. Tsirkin wrote:
> On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote:
>
>> On 06/07/2010 04:37 PM, Anthony Liguori wrote:
>>
>>> On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote:
>>>
>>>> On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:
>>>>
>>>>> On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:
>>>>>
>>>>>> So I see two ways to go forward: switch default value in my patch,
>>>>>> or disable vlans unconditionally.
>>>>>>
>>>>>>
>>>>> The problem with disabling vlans unconditionally is that you break -net
>>>>> socket and -net dump.
>>>>>
>>>>> If we can come up with an alternative way to do these things, I'm all
>>>>> for removing it.
>>>>>
>>>> Hmm, I'll try to look at supporting -net socket in netdev.
>>>> Does -net dump do anything that can't be done with tap+tcpdump?
>>>>
>>> tap+tcpdump requires root privileges (even if you have a tap helper).
>>>
>>> Plus tcpdump doesn't help with slirp and -net dump is very useful for
>>> debugging slirp.
>>>
> Developer's need for root access for debugging seems a reasonable price to
> pay to prevent user confusion and complexity that we have now.
>
Removing vlans has the potential to break existing deployments. That's
something we need to do very cautiously.
What do we gain from removing vlan support today?
Regards,
Anthony Liguori
>> Of course, you could add this functionality to netdev. It's arguably
>> better there too because then you can debug virtio-net+tap with full
>> offload enabled (which you cannot do today).
>>
>> Regards,
>>
>> Anthony Liguori
>>
> Care taking on it? I never even heard about -net dump before today.
>
>
next prev parent reply other threads:[~2010-06-08 13:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 15:03 [Qemu-devel] [PATCH] configure: add an option to disable vlans Michael S. Tsirkin
2010-06-07 16:16 ` Paul Brook
2010-06-07 16:17 ` Michael S. Tsirkin
2010-06-07 16:42 ` Paul Brook
2010-06-07 16:52 ` Anthony Liguori
2010-06-07 19:21 ` Michael S. Tsirkin
2010-06-07 20:40 ` Anthony Liguori
2010-06-07 20:58 ` Michael S. Tsirkin
2010-06-07 21:37 ` Anthony Liguori
2010-06-07 21:57 ` Anthony Liguori
2010-06-08 12:13 ` Michael S. Tsirkin
2010-06-08 13:03 ` Anthony Liguori [this message]
2010-06-08 13:07 ` Michael S. Tsirkin
2010-06-08 11:09 ` Michael S. Tsirkin
2010-06-08 13:02 ` Anthony Liguori
2010-06-08 13:14 ` Michael S. Tsirkin
2010-06-08 14:25 ` Gerd Hoffmann
2010-06-08 14:37 ` Paul Brook
2010-06-08 18:01 ` Anthony Liguori
2010-06-07 17:41 ` Michael S. Tsirkin
2010-06-09 7:44 ` Markus Armbruster
2010-06-10 7:20 ` Chris Webb
2010-06-10 8:43 ` Michael S. Tsirkin
2010-06-08 12:17 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0E3FA5.9060905@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=mst@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).