From nobody Sat Jul 15 00:07:03 2023 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R2pYk2TRXz4n6yN for ; Sat, 15 Jul 2023 00:07:06 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R2pYj2zs5z4Hv6 for ; Sat, 15 Jul 2023 00:07:05 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-31422f20399so562890f8f.1 for ; Fri, 14 Jul 2023 17:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689379624; x=1691971624; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lIDG824+HsY6Myl8PFO3rB1UaUbtzDt1UklcIoQuSA4=; b=DgqNLtTvxY9k3GgcBVxGS8cvPbtJ8kG1dLo1nxy6LHtlpwz+ZDYiniimDWN/ChmZVU cF70unLC3Iw46L9McLsql7wIUwKIesWbICgOw+mTdtdHLUvyY+A1XsA8t6sFMnhVruVG 3mFg6kv2YifnUvKSm6eYxN9pAa1OPcSSipZNf11IeRuJ1eRLzADokGGZ8Obe1+8NajHR QI5u18zhckEirbYCQVZsXmTi3DZSBpYasppQyYKENSyl3xLU/XBPM6bCkERaAnSVYifd 33rqs2ZYPPKjb2kztQJiUiMt+K8myU0dFqhAybqMG14HqlWta03Mea+++f0QKng6lHZt cYrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689379624; x=1691971624; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lIDG824+HsY6Myl8PFO3rB1UaUbtzDt1UklcIoQuSA4=; b=R+rSElOEh7SGqgT+n3fPmY+BAJZIjwwk+90CkeZ0MrNxyAqcjpe42R8frbIraSOtUf U7+MxjY4xeyMuDSUiT+d9idUo5jwztJgwfn0HamSqWwOCLev22P4720XlDILxSoD4xDH gs7EFyY8QRWrIEQzkLNqEKC1mH9XFjFkAttVpla17wGfVUABO5v1EuaAQq46m8BydytA EyLyBN6X1piIxkhnrCQ2MTFU9tgQ3bHV8QNzmPyAelMJvPfpvM5FQ/wrMcQ799TBgVLG WNP0Zxe5wAcQn6u5aiQeaKaDPvcC0/wwglbw57K4ANj8oKZqMj6i6owf5sE3cpMYzSkI jhCA== X-Gm-Message-State: ABy/qLbJ/vuo1FUdm0I0L3nrZSP6dbeQhIFWh4qehJZVzUp6uEYjm7Ih ImSN6QADLFgzFmWdZ/ZOTLIY8al+jSpTafG5CDEoMfEm X-Google-Smtp-Source: APBJJlGSIG5ipgB91AUPf1SAqeCdpArRl9Rp28KrnCKaFgeHUfHn+bnV9Q3X7X1CqTkK2/ldhKlQiEX8ny7NqFFJcWo= X-Received: by 2002:a05:600c:474f:b0:3f7:fb5d:6e7a with SMTP id w15-20020a05600c474f00b003f7fb5d6e7amr435135wmo.0.1689379623696; Fri, 14 Jul 2023 17:07:03 -0700 (PDT) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 Received: by 2002:a17:907:970d:b0:982:69cd:7365 with HTTP; Fri, 14 Jul 2023 17:07:03 -0700 (PDT) In-Reply-To: <3973013d-c183-360f-d7ca-ca822859c23d@shrew.net> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> <986A83D8-E0E0-4030-9369-A5B3500E27C6@gmail.com> <79fabe94-b800-c713-48ea-518da1f74e4d@shrew.net> <3973013d-c183-360f-d7ca-ca822859c23d@shrew.net> From: Rob Wing Date: Fri, 14 Jul 2023 16:07:03 -0800 Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Matthew Grooms Cc: "virtualization@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000005c7d1d06007b5815" X-Rspamd-Queue-Id: 4R2pYj2zs5z4Hv6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000005c7d1d06007b5815 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The review you referenced requires multiple files for a snapshot, which I think is a non-starter. I was trying to ensure that the limitations described in the original snapshot commit message are addressed appropriately - but maybe I've mis-interpreted the message or that I don't fully understand the problem. I don't want give unhelpful or contradictory suggestions to what you've received in the past. The best I can do at this point is defer to those who you have made these agreements with. On Friday, July 14, 2023, Matthew Grooms wrote: > On 7/14/23 13:08, Rob Wing wrote: > >> >> >> On Fri, Jul 14, 2023 at 9:40=E2=80=AFAM Matthew Grooms > > wrote: >> >> >> I see a need to define a format for bhyve so it's possible to mix >> different sections and encodings inside a unified stream. But all th= e >> data in your nvlist example above can be easily be represented as >> text. >> We already have JSON, YAML, XML, etc ... By adopting an preexisting >> format, we could retain the snapshot structure instead of lifting it >> up >> into the stream format. Even if we decide to break the structure up >> into >> different nvlist stream sections, using a common format would allow >> other tools to more easily parse and validate the structure inside >> these >> sections. Isn't that a good thing? Is there a reason we're trying to >> reinvent the wheel here? >> >> >> Does JSON support storing binary data? I'm under the impression that it >> does not. >> > > Hi Rob, > > When we spoke to John Baldwin and others in the community about being abl= e > to remove the #ifdef's from the snapshot code, we were told that copying > binary data structures to a state file was the wrong approach and that a > better method needed to be provided. We agreed. That's why the following > work was undertaken to provide a rich file format that describes the > component values of device's state instead of codifying the c structure i= n > the file format ... > > https://reviews.freebsd.org/D29262 > > When Vitaliy added comments to that review WRT an nvlist based approach, = I > assumed that meant preserving the decomposition of device information tha= t > the UPB team spent so much effort trying to extract. I should have read t= he > original file format proposal email before I replied as I tried too hard = to > interpret it info through that lens. My mistake. > > If Vitaliy, and apparently you, favor the continued practice of copying > data from c structure pointers directly into files to save device state, = I > have no more comments on that approach. Maybe John or UPB will chime in > here with feedback that's more helpful. > > -Matthew > --0000000000005c7d1d06007b5815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The review you referenced requires multiple files for a snapshot, which I t= hink is a non-starter.

I was trying to ensure that the l= imitations described in the original snapshot commit message are addressed = appropriately - but maybe I've mis-interpreted the message or that I do= n't fully understand the problem.

I don't = want give unhelpful or contradictory suggestions to what you've receive= d in the past.

The best I can do at this point is = defer to those who you have made these agreements with.

On Friday, J= uly 14, 2023, Matthew Grooms <mgroo= ms@shrew.net> wrote:
On 7/14/23 13= :08, Rob Wing wrote:


On Fri, Jul 14, 2023 at 9:40=E2=80=AFAM Matthew Grooms <mgrooms@shrew.net <mailto:mgrooms@shrew.net&g= t;> wrote:


=C2=A0 =C2=A0 I see a need to define a format for bhyve so it's possibl= e to mix
=C2=A0 =C2=A0 different sections and encodings inside a unified stream. But= all the
=C2=A0 =C2=A0 data in your nvlist example above can be easily be represente= d as text.
=C2=A0 =C2=A0 We already have JSON, YAML, XML, etc ... By adopting an preex= isting
=C2=A0 =C2=A0 format, we could retain the snapshot structure instead of lif= ting it up
=C2=A0 =C2=A0 into the stream format. Even if we decide to break the struct= ure up
=C2=A0 =C2=A0 into
=C2=A0 =C2=A0 different nvlist stream sections, using a common format would= allow
=C2=A0 =C2=A0 other tools to more easily parse and validate the structure i= nside
=C2=A0 =C2=A0 these
=C2=A0 =C2=A0 sections. Isn't that a good thing? Is there a reason we&#= 39;re trying to
=C2=A0 =C2=A0 reinvent the wheel here?


Does JSON support storing binary data? I'm under the impression that it= does not.

Hi Rob,

When we spoke to John Baldwin and others in the community about being able = to remove the #ifdef's from the snapshot code, we were told that copyin= g binary data structures to a state file was the wrong approach and that a = better method needed to be provided. We agreed. That's why the followin= g work was undertaken to provide a rich file format that describes the comp= onent values of device's state instead of codifying the c structure in = the file format ...

https://re= views.freebsd.org/D29262

When Vitaliy added comments to that review WRT an nvlist based approach, I = assumed that meant preserving the decomposition of device information that = the UPB team spent so much effort trying to extract. I should have read the= original file format proposal email before I replied as I tried too hard t= o interpret it info through that lens. My mistake.

If Vitaliy, and apparently you, favor the continued practice of copying dat= a from c structure pointers directly into files to save device state, I hav= e no more comments on that approach. Maybe John or UPB will chime in here w= ith feedback that's more helpful.

-Matthew
--0000000000005c7d1d06007b5815--