All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] net: Silence 'has no peer' messages in testing mode
Date: Wed, 09 May 2018 08:18:42 +0200	[thread overview]
Message-ID: <87tvrhbbct.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <9d66d071-324f-5d33-547d-901f497cb497@redhat.com> (Thomas Huth's message of "Tue, 8 May 2018 15:19:24 +0200")

Thomas Huth <thuth@redhat.com> writes:

> On 07.05.2018 09:14, Markus Armbruster wrote:
> [...]
>> Two (possibly confused) questions:
>> 
>> 1. The user can add nics without convenience options:
>> 
>>     $ upstream-qemu -display none -nodefaults -device e1000
>>     upstream-qemu: warning: nic e1000.0 has no peer
>> 
>>    Shouldn't we silence the warning then, too?
>
> No, since that is certainly a mis-configuration in that case. Why would
> a user want to add a NIC without host backend?

Related:

    $ upstream-qemu -display none -nodefaults -net nic
    upstream-qemu: warning: vlan 0 is not connected to host network

The root of my confusion: I'm having difficulties making the connection
from the guard predicate (!qtest_enabled() || nd_table[0].used) to
"stupid default setup that isn't the test's fault".

In what scenarios exactly do we get unwanted "has no peer" messages?
Mandatory onboard NIC, perhaps?

Arguably, onboard NICs should default to a null backend that behaves
like "no carrier".  That's exactly what physical hardware does.  Could
even be useful outside tests once we support hot-plugging network
backends (we might already, I have no idea), just like physical hardware
supports plugging in network cables.

[...]

      reply	other threads:[~2018-05-09  6:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03  5:50 [Qemu-devel] [PATCH] net: Silence 'has no peer' messages in testing mode Thomas Huth
2018-05-03 11:47 ` Markus Armbruster
2018-05-04 14:55   ` Thomas Huth
2018-05-07  7:14     ` Markus Armbruster
2018-05-08 13:19       ` Thomas Huth
2018-05-09  6:18         ` Markus Armbruster [this message]

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=87tvrhbbct.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.