On 07/03/2022 09.05, Marc-André Lureau wrote:
Hi
On Mon, Mar 7, 2022 at 11:46 AM Thomas Huth <th...@redhat.com
<mailto:th...@redhat.com>> wrote:
On 07/03/2022 08.03, marcandre.lur...@redhat.com
<mailto:marcandre.lur...@redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lur...@redhat.com
<mailto:marcandre.lur...@redhat.com>>
>
> glib provides a convenience helper to measure elapsed time. It isn't
> subject to wall-clock time changes.
>
> Note that this changes the initial OPENED time, which used to print the
> current time.
[...]
> @@ -846,21 +828,20 @@ static void qtest_event(void *opaque,
QEMUChrEvent event)
> for (i = 0; i < ARRAY_SIZE(irq_levels); i++) {
> irq_levels[i] = 0;
> }
> - qemu_gettimeofday(&start_time);
> +
> + g_clear_pointer(&timer, g_timer_destroy);
> + timer = g_timer_new();
> qtest_opened = true;
> if (qtest_log_fp) {
> - fprintf(qtest_log_fp, "[I " FMT_timeval "] OPENED\n",
> - (long) start_time.tv_sec, (long)
start_time.tv_usec);
> + fprintf(qtest_log_fp, "[I " FMT_timeval "] OPENED\n",
g_timer_elapsed(timer, NULL));
> }
> break;
The new timestamp here is quite unuseful now, of course ... could you
replace it with g_get_current_time() instead?
Eventually, but I wonder why this (and only this) particular timestamp
should be the current time.
I assume it was meant as a possibility to sync the times in this log with
other things that are going on on the host system in parallel. If you only
have the relative time stamps in the log here, you cannot compare the events
to other logs anymore.
(having said that, I wonder why it doesn't simply always use the current
wall time and uses the relative time instead, but maybe there is also a
reason for that...)
Thomas
