From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] net: Next steps to deprecate -net
Date: Wed, 22 Jul 2015 15:40:55 +0200 [thread overview]
Message-ID: <87615cl388.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <55A8B352.2090605@redhat.com> (Thomas Huth's message of "Fri, 17 Jul 2015 09:48:34 +0200")
Copying Andreas just in case.
Thomas Huth <thuth@redhat.com> writes:
> On 07/17/2015 09:25 AM, Peter Maydell wrote:
>> On 17 July 2015 at 07:53, Thomas Huth <thuth@redhat.com> wrote:
>>> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
>>> series is going to solve the dumping-for-netdev problem, how do we
>>> tackle the remaining problems that we have to solve before we can
>>> deprecate -net? Does anybody have a survey of the (onboard) NICs that
>>> can only be configured with -net but not with -device? Could they
>>> nowadays be changed to work with -device, too, or are there still major
>>> obstacles to solve first?
>>
>> The problem is that "-device" says "create a new device and
>> configure it like this". But onboard NICs are created by
>> the board, so we want let the user say how to configure
>> those devices, not create new ones...
The more general problem is lack of a uniform way to configure onboard
devices.
We have a bunch of ways to configure onboard devices: -net nic, -serial,
-parallel, -drive, ... These all deposit configuration requests in
well-known places for the board code to pick up. A request can apply
(a) to a mandatory onboard device, modifying its configuration, or
(b) to an optional onboard device, triggering its creation, or
(c) to nothing in particular.
It all depends on the board code.
For qdevified devices, you can replace (b) with -device, but not (a), as
Peter points out.
To likewise replace (a), we'd need means to change an *existing*
device's properties. Complication: how to address the device. Onboard
devices don't have a qdev ID... QOM path?
Aside: you can sometimes use -global to replace (a), but it's not
general, because -global applies to all devices of a certain type, not
just the one you're actually targeting.
> Ok, I see ... maybe it makes sense to simply keep "-net nic" to be able
> to configure the default/onboard NIC, and only to remove all the other
> -net options instead ("-net user" etc.). The disliked vlan/hub concept
> could then be removed, too, since "-net nic" can be used together with
> "-netdev" nowadays by using something like "-net nic,netdev=xxx" as far
> as I know. That would clean up most points of confusion, I think, and
> would not cause too much code churn for the onboard NICs. Does that
> sound feasible?
Deprecating -net except for -net nic sounds like a fine step forward to
me.
next prev parent reply other threads:[~2015-07-22 13:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 19:22 [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too, Thomas Huth
2015-05-22 19:42 ` Eric Blake
2015-05-26 12:52 ` Stefan Hajnoczi
2015-05-26 13:07 ` Thomas Huth
2015-05-26 18:25 ` Paolo Bonzini
2015-05-26 14:29 ` Markus Armbruster
2015-05-26 14:36 ` Daniel P. Berrange
2015-05-26 16:43 ` Stefan Hajnoczi
2015-05-26 18:15 ` Thomas Huth
2015-05-27 7:22 ` Markus Armbruster
2015-07-17 6:53 ` [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too) Thomas Huth
2015-07-17 7:25 ` Peter Maydell
2015-07-17 7:48 ` [Qemu-devel] net: Next steps to deprecate -net Thomas Huth
2015-07-22 13:40 ` Markus Armbruster [this message]
2015-07-22 16:20 ` Michael S. Tsirkin
2015-07-22 16:45 ` Thomas Huth
2015-07-17 8:16 ` [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too) Stefan Hajnoczi
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=87615cl388.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=afaerber@suse.de \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--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.