From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8tCl-0003Q6-HF for qemu-devel@nongnu.org; Tue, 15 Dec 2015 12:16:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8tCi-0003Rb-6s for qemu-devel@nongnu.org; Tue, 15 Dec 2015 12:16:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8tCh-0003RW-VL for qemu-devel@nongnu.org; Tue, 15 Dec 2015 12:16:00 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 83D2E42E5CE for ; Tue, 15 Dec 2015 17:15:59 +0000 (UTC) References: <1450179992-15959-1-git-send-email-thuth@redhat.com> <56700CBA.5010505@redhat.com> <56703969.9050905@redhat.com> <56703E09.5000504@redhat.com> From: Thomas Huth Message-ID: <56704ACB.8010909@redhat.com> Date: Tue, 15 Dec 2015 18:15:55 +0100 MIME-Version: 1.0 In-Reply-To: <56703E09.5000504@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] net: Inform the user about deprecated -net options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org, Jason Wang Cc: Markus Armbruster On 15/12/15 17:21, Paolo Bonzini wrote: >=20 >=20 > On 15/12/2015 17:01, Thomas Huth wrote: >> Some options work with "-net", some only work with "-netdev", >> and the ones that work with both often also behave slightly differentl= y (see >> [1] for example). >=20 > This example is about -net nic, which you're keeping. What are the > options that differ between them for network backends? The vlan option only exists for the "-net" backends. And I somehow thought that all the vhost related stuff would only work with the "-netdev", but I can not spot that in the code anymore, so I guess I simply got that wrong. >> One other example is the "-net nic,model=3D?" help text. It is inaccur= ate for a >> couple of machines - and if somebody tries to fix problems like this, = you're >> often told something like "oh, it's the legacy -net option, simply for= get about >> that" [2]. >=20 > Nobody mentioned legacy in that thread... Alex just said *he* would no= t > bother, but if you could come up with a better way to do it, it would > surely be accepted. Ok, maybe should have cited this one here instead: https://lists.gnu.org/archive/html/qemu-ppc/2013-11/msg00040.html Markus said: "My advice would be to let -net nic rot in peace." > For example you could print all DEVICE_CATEGORY_NETWORK devices that > support device_add. I think that would not work since spapr-vlan is not hot-pluggable. >> And if you additionally ever had to deal with all that vlan code and d= uplicated >> option parsing stuff in the net/ code, then you certainly do not think= anymore >> that this is just a little bit more than "syntactic sugar". >=20 > In fact there isn't much shared code in the is_netdev=3D0 and is_netdev= =3D1 > cases. Perhaps you could just make a shared function with just >=20 > if (net_client_init_fun[opts->type](opts, name, peer, errp) < 0) { > /* FIXME drop when all init functions store an Error */ > if (errp && !*errp) { > error_setg(errp, QERR_DEVICE_INIT_FAILED, > NetClientOptionsKind_lookup[opts->type]); > } > return -1; > } >=20 >=20 > and inline all the rest of net_client_init1, net_visit, net_client_init > into two functions netdev_add and net_legacy_add. Then -net handling > (including HMP) can be moved into a separate file which no one looks at= . Well, moving the code into a file "which no one looks at" does not really solve the problem. When you want to modify the net code, you can not simply ignore this since it is still there and needs to be kept alive when it breaks or does not compile anymore. >> I'm fine if we keep the "-net" options for a couple of more versions o= f QEMU, >> but we should be prepared to be able to remove it quickly once it is g= etting into >> the way again too much. So we better start nagging the users about "-n= et" being >> deprecated now, than discovering later that we have to deal with this = legacy >> stuff for longer than we would like to. >=20 > The thing is, people are still running QEMU from the command line. >=20 > "-net nic -net bridge,br=3Dvirbr0" is still much less of a mouthful tha= n > "-netdev bridge,br=3Dvirbr0,id=3Dbr -device rtl8139,netdev=3Dbr" if all= I want > is something I can ssh into. >=20 > It's easy to deprecate things. It's hard to convince users that it's > worth, and you haven't convinced this user. :) Ok, if you want to maintain that legacy stuff forever - fine. I thought it would be a good idea to slowly get rid off it, but honestly, if there's so much resistance ... I've also got other stuff to do, so simply forget about this. Thomas