From: Paolo Bonzini <pbonzini@redhat.com>
To: Thomas Huth <thuth@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
Roman Kagan <rkagan@virtuozzo.com>, Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 03/17] iotests: ask qemu for supported formats
Date: Thu, 7 Jun 2018 13:18:23 +0200 [thread overview]
Message-ID: <a9e7a3d9-4453-f9e1-9a00-fc9df42a0d47@redhat.com> (raw)
In-Reply-To: <b010eb74-9ac5-014c-723d-82ba462f99b8@redhat.com>
On 07/06/2018 13:10, Thomas Huth wrote:
> On 07.06.2018 13:07, Paolo Bonzini wrote:
>> On 07/06/2018 09:50, Thomas Huth wrote:
>>>
>>>> There's no real need to kill off '?', unless it gets in the way of
>>>> steering people towards 'help'. We should steer them toward 'help',
>>>> because '?' is a trap for insufficiently sophisticated users of
>>>> shell[*].
>>> ... and I agree with your points here.
>>>
>>> => I think we need a second list of deprecated feature (maybe we should
>>> call them "legacy features" instead of "deprecated"?), i.e. a list of
>>> features which we don't recommend for new code / scripts anymore, but
>>> which we do not intend to remove via our official deprecation policy any
>>> time soon. Things like "--enable-kvm" / "-no-kvm" or maybe even "-net"
>>> go into the same category.
>>
>> Yes, "-net" definitely goes there.
>>
>>> If you agree, I can try to come up with a patch (should the list go into
>>> qemu-doc.texi or a separate document in the the documentation folder?).
>>
>> I think it should go in docs/devel.
>
> I currently rather tend to put it into a new appendix in qemu-doc.texi,
> since this is useful information for the normal users, too. Or how shall
> we communicate this to the users that the old options that they are used
> to are still there, but should not be used for new scripts anymore?
I think we should tell them directly in the text for things like "-net".
The new document would put things together and be mostly about
command-line (anti)patterns.
As to "-enable-kvm", I don't see anything wrong with users using it, or
even with occasionally adding more options like it. However, we should
warn developers that such simple options should be syntactic sugar for a
structured (i.e. QemuOpts-based) option like "-accel", and that it
should only be done for similarity with existing options. Basically the
same reason why new options have both "?" and "help", even though "?" is
disliked.
Paolo
next prev parent reply other threads:[~2018-06-07 11:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 16:19 [Qemu-devel] [PATCH 00/17] iotests: don't choke on disabled drivers Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 01/17] block: iterate_format with account of whitelisting Roman Kagan
2018-04-26 18:15 ` Eric Blake
2018-05-30 12:03 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 02/17] iotests: iotests.py: prevent deadlock in subprocess Roman Kagan
2018-05-30 12:07 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 03/17] iotests: ask qemu for supported formats Roman Kagan
2018-05-30 12:17 ` Max Reitz
2018-05-30 13:07 ` Roman Kagan
2018-06-04 7:18 ` Markus Armbruster
2018-06-04 10:34 ` Thomas Huth
2018-06-04 22:40 ` Eric Blake
2018-06-05 4:02 ` Thomas Huth
2018-06-07 6:57 ` Markus Armbruster
2018-06-07 7:50 ` Thomas Huth
2018-06-07 11:07 ` Paolo Bonzini
2018-06-07 11:10 ` Thomas Huth
2018-06-07 11:18 ` Paolo Bonzini [this message]
2018-06-07 11:27 ` [Qemu-devel] -enable-kvm and friens (was: Re: [PATCH 03/17] iotests: ask qemu for supported formats) Thomas Huth
2018-06-07 11:42 ` Paolo Bonzini
2018-06-07 11:51 ` [Qemu-devel] -enable-kvm and friens Thomas Huth
2018-06-07 11:29 ` [Qemu-devel] [PATCH 03/17] iotests: ask qemu for supported formats Markus Armbruster
2018-06-07 12:42 ` Daniel P. Berrangé
2018-04-26 16:19 ` [Qemu-devel] [PATCH 04/17] iotest 030: skip quorum test setup/teardown too Roman Kagan
2018-05-30 12:19 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 05/17] iotest 030: require blkdebug Roman Kagan
2018-05-30 12:19 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 06/17] iotest 055: skip unsupported backup target formats Roman Kagan
2018-05-30 12:22 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 07/17] iotest 055: require blkdebug Roman Kagan
2018-05-30 12:22 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 08/17] iotest 056: skip testcases using blkdebug if disabled Roman Kagan
2018-05-30 12:26 ` Max Reitz
2018-04-26 16:19 ` [Qemu-devel] [PATCH 09/17] iotest 071: notrun if blkdebug or blkverify is disabled Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 10/17] iotest 081: notrun if quorum " Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 11/17] iotest 087: notrun if null-co " Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 12/17] iotest 093: notrun if null-co or null-aio " Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 13/17] iotest 099: notrun if blkdebug or blkverify " Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 14/17] iotest 124: skip testcases using blkdebug if disabled Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 15/17] iotest 139: skip testcases using disabled drivers Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 16/17] iotest 147: notrun if nbd is disabled Roman Kagan
2018-04-26 16:19 ` [Qemu-devel] [PATCH 17/17] iotest 184: notrun if null-co or throttle " Roman Kagan
2018-04-26 16:47 ` [Qemu-devel] [PATCH 00/17] iotests: don't choke on disabled drivers no-reply
2018-05-17 16:11 ` [Qemu-devel] [Qemu-block] " Roman Kagan
2018-05-30 12:35 ` [Qemu-devel] " Max Reitz
2018-05-30 13:47 ` Roman Kagan
2018-05-30 13:53 ` Max Reitz
2018-05-30 14:16 ` Roman Kagan
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=a9e7a3d9-4453-f9e1-9a00-fc9df42a0d47@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rkagan@virtuozzo.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 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).