From: Peter Xu <peterx@redhat.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
Leonardo Bras <leobras@redhat.com>
Subject: Re: [PATCH V1] migration: export fewer options
Date: Tue, 27 Feb 2024 16:08:25 +0800 [thread overview]
Message-ID: <Zd2YeQAXhUCZzYdM@x1n> (raw)
In-Reply-To: <65ec5d47-d27a-4633-ad3c-aec8a7710f8b@oracle.com>
On Mon, Feb 26, 2024 at 09:41:15AM -0500, Steven Sistare wrote:
> On 2/26/2024 2:40 AM, Markus Armbruster wrote:
> > Steve Sistare <steven.sistare@oracle.com> writes:
> >
> >> A small number of migration options are accessed by migration clients,
> >> but to see them clients must include all of options.h, which is mostly
> >> for migration core code. migrate_mode() in particular will be needed by
> >> multiple clients.
> >>
> >> Refactor the option declarations so clients can see the necessary few via
> >> misc.h, which already exports a portion of the client API.
> >>
> >> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> >> ---
> >> I suggest that eventually we should define a single file migration/client.h
> >> which exports everything needed by the simpler clients: blockers, notifiers,
> >> options, cpr, and state accessors.
> >> ---
> >> ---
> >> hw/vfio/migration.c | 1 -
> >> hw/virtio/virtio-balloon.c | 1 -
> >> include/migration/misc.h | 1 +
> >> include/migration/options-pub.h | 24 ++++++++++++++++++++++++
> >> migration/options.h | 6 +-----
> >
> > Unusual naming. We have zero headers named -pub.h or -public.h, and
> > dozens named like -int.h or -internal.h. Please stick to the existing
> > convention.
>
> In the spirit of minimizing changes, I went that route to avoid renaming the
> existing migration/options.h and its references:
>
> 0 migration/block-dirty-bit 82 #include "options.h"
> 1 migration/block.c 32 #include "options.h"
> 2 migration/colo.c 37 #include "options.h"
> 3 migration/migration-hmp-c 35 #include "options.h"
> 4 migration/migration.c 68 #include "options.h"
> 5 migration/multifd-zlib.c 21 #include "options.h"
> 6 migration/multifd-zstd.c 21 #include "options.h"
> 7 migration/multifd.c 29 #include "options.h"
> 8 migration/options.c 30 #include "options.h"
> 9 migration/postcopy-ram.c 40 #include "options.h"
> a migration/qemu-file.c 33 #include "options.h"
> b migration/ram-compress.c 37 #include "options.h"
> c migration/ram.c 63 #include "options.h"
> d migration/rdma.c 40 #include "options.h"
> e migration/savevm.c 71 #include "options.h"
> f migration/socket.c 30 #include "options.h"
> g migration/tls.c 25 #include "options.h"
>
> But I take your point.
>
> Peter, which do you prefer?
From statistics, "-internal.h" wins "-int.h":
$ git grep "\-internal.h" | wc -l
135
$ git grep "\-int.h" | wc -l
3
>
> A. rename: migration/options.h -> migration/options-internal.h
> rename: include/migration/options-pub.h -> include/migration/options.h
>
> B. rename: include/migration/options.h -> include/migration/client-options.h
>
> I prefer B. If you prefer B, but want a different file name, please choose the
> final name.
Personally I don't have a strong opinion on the name. I'll see whether
Markus has any comment.
[and of course, I removed this patch from -staging queue to keep the
discussion going..]
--
Peter Xu
next prev parent reply other threads:[~2024-02-27 8:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 17:13 [PATCH V1] migration: export fewer options Steve Sistare
2024-02-26 2:40 ` Peter Xu
2024-02-26 16:45 ` Steven Sistare
2024-02-26 7:40 ` Markus Armbruster
2024-02-26 14:41 ` Steven Sistare
2024-02-27 8:08 ` Peter Xu [this message]
2024-02-27 13:15 ` Steven Sistare
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=Zd2YeQAXhUCZzYdM@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=farosas@suse.de \
--cc=leobras@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.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).