From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHwki-0007rO-4u for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:20:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHwkd-00010t-4j for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:20:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHwkc-00010e-Tu for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:20:11 -0400 Date: Wed, 22 Jul 2015 19:20:07 +0300 From: "Michael S. Tsirkin" Message-ID: <20150722191937-mutt-send-email-mst@redhat.com> References: <1432322539-23719-1-git-send-email-thuth@redhat.com> <20150526125235.GJ13262@stefanha-thinkpad.redhat.com> <87egm34dk0.fsf@blackfin.pond.sub.org> <55A8A654.5070003@redhat.com> <55A8B352.2090605@redhat.com> <87615cl388.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87615cl388.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] net: Next steps to deprecate -net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Thomas Huth , Jason Wang , QEMU Developers , Stefan Hajnoczi , Andreas =?iso-8859-1?Q?F=E4rber?= On Wed, Jul 22, 2015 at 03:40:55PM +0200, Markus Armbruster wrote: > Copying Andreas just in case. > > Thomas Huth writes: > > > On 07/17/2015 09:25 AM, Peter Maydell wrote: > >> On 17 July 2015 at 07:53, Thomas Huth 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. -net dump is also useful, we'll need some solution for that if we want to deprecate vlans. -- MST