From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGLI5-0003fy-78 for qemu-devel@nongnu.org; Wed, 28 Jan 2015 00:35:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGLI3-0001Vu-Df for qemu-devel@nongnu.org; Wed, 28 Jan 2015 00:35:49 -0500 Date: Wed, 28 Jan 2015 16:28:24 +1100 From: David Gibson Message-ID: <20150128052824.GA14681@voom> References: <1419293824-2654-1-git-send-email-david@gibson.dropbear.id.au> <1419293824-2654-9-git-send-email-david@gibson.dropbear.id.au> <5498B6D2.5040406@suse.de> <20141223031456.GB4576@voom.redhat.com> <7B1D741A-D9FD-4CE8-B6EB-C37D89BE6B5B@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <7B1D741A-D9FD-4CE8-B6EB-C37D89BE6B5B@suse.de> Subject: Re: [Qemu-devel] [PATCHv2 8/8] pseries: Export RTC time via QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "aik@ozlabs.ru" , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , "mdroth@us.ibm.com" , "amit.shah@redhat.com" , "pbonzini@redhat.com" --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 23, 2014 at 07:33:30AM +0100, Alexander Graf wrote: >=20 >=20 >=20 > > Am 23.12.2014 um 04:14 schrieb David Gibson : > >=20 > >> On Tue, Dec 23, 2014 at 01:26:58AM +0100, Alexander Graf wrote: > >>=20 > >>=20 > >>> On 23.12.14 01:17, David Gibson wrote: > >>> On x86, the guest's RTC can be read with QMP, either from the RTC dev= ice's > >>> "date" property or via the "rtc-time" property on the machine (which = is an > >>> alias to the former). This is set up in the mc146818rtc driver, and > >>> doesn't work on other targets. > >>>=20 > >>> This patch adds a similar "date" property to the pseries machine's RT= AS RTC > >>> and adds a compatible alias to the machine. > >>>=20 > >>> Signed-off-by: David Gibson > >>=20 > >> Very nice, can we somehow get rid of an exported spapr_rtc_read() with > >> this as well? > >=20 > > Uhhh.. we could, but I really don't like the idea. > >=20 > > It seems perverse to encode the current time into JSON, just so we can > > decode it into a struct tm again in the events code. >=20 > I don't understand - what does JSON have to do with it? My misunderstanding, it doesn't actually deal with JSON here. But if I'm following how this would work, it would be a way of getting a struct tm from point A to point B, by: 1. building a temporary visitor object (object_property_get_qobject) 2. finding and calling the general property getter callback (object_property_get) 3. Making multiple callbacks into the visitor with pieces of point A's struct tm (property_get_tm) 4. In those visitor callbacks building an associative array (qmp_output_start_struct), then filling it with object wrappers around integers (qmp_output_type_int) 5. Digging through the nested qobject thus constructed to extract the various ints and put them into point B's struct tm (hypothetical object_property_get_tm) 6. Cleaning up the various temporaries created during the process Seriously, w. t. f.!? Maybe there's a simpler way of doing this via the object property mechanism, but it's sure as hell not obvious to me. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUyHN4AAoJEGw4ysog2bOSn4kQAJpR4P2dhWqmf0DcqNWkNjOh 9AHHHevLjbexvcG3qfZARD7ylHo9guOxr5BzWnQjiV8BxmSC38uuAl0hJYgV79Cj OxOizQJUs3YRhB+npx/uPtP/snJh2KZrHMGYXqXSd5NKKHv4m024zKkYCaJdI4ny ArZtmqpeSSOIZWpvX1W4EreD4KUqHhy2ilkpo923HF5a2mEQkm9GFO0z1IKfLqN+ tYVXEE+SBglwEljbqNN0eQ8EfibPz8b+0fEQBUvXJbY1VqWj08XRyRIXuBy+g7qf Zvv4zYl3op8kR9CI5tdogj7OpYqW8K21PO4jIFCQs9cmvBYunhQUVg1v3OQQsbMh gsW5zM/8cGgTrLUP17UOX2cK1bXHd0UrQlw415cEDfydEuosU936tuiAduiWz6cp qhi0gv77yD0AycsoryH6mvw+9fI5xnzdUp9lEPdvFQ7RSFCCSxDF58EMXQk2Qlma M38+2CltYO/5bZCmh7Oz93vMDUO07usw9VM8tYDcV77Ptz90z1PSGVsxMolEuUQH Bg8jMf1dd6GFoQ06PVi4X7+f7llJw7Xl03nHqP8JVMXy2RmbckaX4THjt82iKLea IhR9iL3T7MY3nhSFn4Y9dDhqACRsGKCHNPUGo2rEL2AkUAEcUCbCaTUiv9Hz1DUy 7v4yrhZF+yACrImTvshN =zPN1 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi--