From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8sM4-0004Xe-Hm for qemu-devel@nongnu.org; Tue, 15 Dec 2015 11:21:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8sM1-0003wk-8z for qemu-devel@nongnu.org; Tue, 15 Dec 2015 11:21:36 -0500 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:35515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8sM1-0003w9-3K for qemu-devel@nongnu.org; Tue, 15 Dec 2015 11:21:33 -0500 Received: by mail-wm0-x22d.google.com with SMTP id l126so1327164wml.0 for ; Tue, 15 Dec 2015 08:21:32 -0800 (PST) Sender: Paolo Bonzini References: <1450179992-15959-1-git-send-email-thuth@redhat.com> <56700CBA.5010505@redhat.com> <56703969.9050905@redhat.com> From: Paolo Bonzini Message-ID: <56703E09.5000504@redhat.com> Date: Tue, 15 Dec 2015 17:21:29 +0100 MIME-Version: 1.0 In-Reply-To: <56703969.9050905@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Thomas Huth , qemu-devel@nongnu.org, Jason Wang 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 differently (see > [1] for example). This example is about -net nic, which you're keeping. What are the options that differ between them for network backends? > One other example is the "-net nic,model=?" help text. It is inaccurate 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 forget about > that" [2]. Nobody mentioned legacy in that thread... Alex just said *he* would not bother, but if you could come up with a better way to do it, it would surely be accepted. For example you could print all DEVICE_CATEGORY_NETWORK devices that support device_add. > And if you additionally ever had to deal with all that vlan code and duplicated > 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". In fact there isn't much shared code in the is_netdev=0 and is_netdev=1 cases. Perhaps you could just make a shared function with just 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; } 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. > I'm fine if we keep the "-net" options for a couple of more versions of QEMU, > but we should be prepared to be able to remove it quickly once it is getting into > the way again too much. So we better start nagging the users about "-net" being > deprecated now, than discovering later that we have to deal with this legacy > stuff for longer than we would like to. The thing is, people are still running QEMU from the command line. "-net nic -net bridge,br=virbr0" is still much less of a mouthful than "-netdev bridge,br=virbr0,id=br -device rtl8139,netdev=br" if all I want is something I can ssh into. It's easy to deprecate things. It's hard to convince users that it's worth, and you haven't convinced this user. :) Paolo