From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Samuel Thibault <samuel.thibault@gnu.org>
Cc: qemu-devel@nongnu.org, quintela@redhat.com, amit.shah@redhat.com,
jan.kiszka@siemens.com, duanj@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 7/8] slirp: VMStatify socket level
Date: Mon, 7 Nov 2016 19:55:32 +0000 [thread overview]
Message-ID: <20161107195532.GB1155@work-vm> (raw)
In-Reply-To: <20161030144712.GE3671@var.home>
* Samuel Thibault (samuel.thibault@gnu.org) wrote:
> Hello,
>
> Dr. David Alan Gilbert (git), on Thu 27 Oct 2016 16:32:16 +0100, wrote:
> > - case AF_INET:
> > - qemu_put_be32(f, so->so_faddr.s_addr);
> > - qemu_put_be16(f, so->so_fport);
> > - break;
>
> > + if (version_id >= 4 && !is_inet) {
> > + error_report("%s: so_ffamily unknown, socket not preserved", __func__);
> > }
>
> Well, no, we need to settle this another way, because we want to be able
> to easily add inet6 support here. At least pave the way in a way that
> makes it not unnecessarily hard. The code you are adding here looks to
> me like very hard to rework to make it support the various socket
> families.
Well, I was just trying to match the current semantics/errors there.
> > + VMSTATE_UINT16_V(so_ffamily, struct socket, 4),
> > + VMSTATE_UINT32_TEST(so_faddr.s_addr, struct socket,
> > + slirp_v4_or_newer_ffamily_inet),
> > + VMSTATE_UINT16_TEST(so_fport, struct socket,
> > + slirp_v4_or_newer_ffamily_inet),
>
> Does VMStat not provide a way to have differing content depending on a
> field? (here, so_ffamily)
It has two things:
a) Versions (e.g. VMSTATE_UINT16_V) - that says only include this field if
we're on version >= n
b) Tests (.e.g. VMSTATE_UINT16_TEST) - that says only include the field
if the test says so. The tests are a bit tedious since they're each
a function, their is no generic test description scheme.
(A lambda here would be lovely, but making one to work on both Gcc and
Clang and anything else isn't trivial; I looked)
I think the underlying macros would make it easy to do a VMSTATE_UINT16_TEST_V
that only happens if both the test and the check are true which might
make this easier.
It's not that hard, but a bit tedious if we wanted to add another family here;
we'd end up with:
VMSTATE_UINT16_V(so_ffamily, struct socket, 4),
VMSTATE_UINT32_TEST(so_faddr.s_addr, struct socket,
slirp_v4_or_newer_ffamily_inet),
VMSTATE_UINT32_TEST(so_faddr.s_addr6, struct socket,
slirp_v4_or_newer_ffamily_inet6),
VMSTATE_UINT16_TEST(so_fport, struct socket,
slirp_v4_or_newer_ffamily_inet),
and change the test to:
static bool slirp_v4_or_newer_ffamily_inet(void *opaque, int version_id)
{
bool is_inet = ((struct socket *)opaque)->so_ffamily == AF_INET;
bool is_inet6 = ((struct socket *)opaque)->so_ffamily == AF_INET6;
if (version_id >= 4 && !is_inet && !is_inet6) {
error_report("%s: so_ffamily unknown, socket not preserved", __func__);
}
return version_id >= 4 && is_inet;
}
static bool slirp_v4_or_newer_ffamily_inet6(void *opaque, int version_id)
{
bool is_inet6 = ((struct socket *)opaque)->so_ffamily == AF_INET6;
return version_id >= 4 && is_inet6;
}
The asymmetry is purely to generate the error.
Actually, I might be able to avoid some of the lfamily/ffamily
duplication here - I hadn't spotted the were macros for lhost.ss.ss_family,
so I think I can rework the v4 or newer by doing:
a) Split the fhost and lhost union's out as a separate union and share
them.
b) For the v4 entries do:
VMSTATE_STRUCT(fhost, struct socket, 4, vmstate_slirp_hosts);
VMSTATE_STRUCT(lhost, struct socket, 4, vmstate_slirp_hosts);
and define vmstate_slirp_hosts to have the logic to check the family;
although I've never tried VMSTATE_STRUCT on a union I think it'll work (!).
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2016-11-07 19:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 15:32 [Qemu-devel] [PATCH 0/8] VMSTATE_WITH_TMP and it's use in SLIRP Dr. David Alan Gilbert (git)
2016-10-27 15:32 ` [Qemu-devel] [PATCH 1/8] migration: extend VMStateInfo Dr. David Alan Gilbert (git)
2017-02-13 12:02 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 2/8] add QEMU_BUILD_BUG_EXPR Dr. David Alan Gilbert (git)
2017-02-13 12:02 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 3/8] migration: Add VMSTATE_WITH_TMP Dr. David Alan Gilbert (git)
2017-02-13 12:04 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 4/8] tests/migration: Add test for VMSTATE_WITH_TMP Dr. David Alan Gilbert (git)
2017-02-13 12:06 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 5/8] slirp: VMState conversion; tcpcb Dr. David Alan Gilbert (git)
2017-02-13 12:06 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 6/8] slirp: VMStatify sbuf Dr. David Alan Gilbert (git)
2016-10-30 14:40 ` Samuel Thibault
2017-02-13 12:07 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 7/8] slirp: VMStatify socket level Dr. David Alan Gilbert (git)
2016-10-30 14:47 ` Samuel Thibault
2016-11-07 19:55 ` Dr. David Alan Gilbert [this message]
2017-02-13 12:13 ` Juan Quintela
2016-10-27 15:32 ` [Qemu-devel] [PATCH 8/8] slirp: VMStatify remaining except for loop Dr. David Alan Gilbert (git)
2016-10-30 14:51 ` Samuel Thibault
2016-11-07 19:30 ` Dr. David Alan Gilbert
2017-02-13 12:09 ` Juan Quintela
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=20161107195532.GB1155@work-vm \
--to=dgilbert@redhat.com \
--cc=amit.shah@redhat.com \
--cc=duanj@linux.vnet.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=samuel.thibault@gnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.