From: Paolo Bonzini <pbonzini@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] net: Inform the user about deprecated -net options
Date: Tue, 15 Dec 2015 17:21:29 +0100 [thread overview]
Message-ID: <56703E09.5000504@redhat.com> (raw)
In-Reply-To: <56703969.9050905@redhat.com>
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
next prev parent reply other threads:[~2015-12-15 16:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 11:46 [Qemu-devel] [PATCH] net: Inform the user about deprecated -net options Thomas Huth
2015-12-15 12:51 ` Paolo Bonzini
2015-12-15 16:01 ` Thomas Huth
2015-12-15 16:21 ` Paolo Bonzini [this message]
2015-12-15 16:46 ` Eric Blake
2015-12-15 17:15 ` Thomas Huth
2015-12-15 17:31 ` Paolo Bonzini
2015-12-15 17:50 ` Thomas Huth
2015-12-15 18:08 ` Paolo Bonzini
2015-12-16 7:20 ` Thomas Huth
2015-12-16 8:50 ` Paolo Bonzini
2015-12-15 16:17 ` Peter Maydell
2015-12-15 16:33 ` Thomas Huth
2015-12-15 16:46 ` Peter Maydell
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=56703E09.5000504@redhat.com \
--to=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).