[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 03/12] qemu-timer: more clock functions

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 03/12] qemu-timer: more clock functions
Date: Fri, 30 Sep 2011 13:03:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

On 09/30/2011 12:52 PM, Lluís Vilanova wrote:
Paolo Bonzini writes:

These will be used when moving icount accounting to cpus.c.

I have something related to this kind of refactoring. While trying to understand
all the timing facilities in QEMU, I wrote some (unfinished) patches that try to
disentangle much of the code in qemu-timer into two new files:

- qemu-htime: Provides routines related to time in the host.
- qemu-vtime: Provides routines related to time in the guest.

These patches also try to sanitize some routine names by making their domain and
units explicit (e.g., get_clock becomes qemu_htime_nsec and cpu_get_ticks
becomes qemu_vtime_tsc).

That's almost unnecessary, get_clock should be just qemu_get_clock_ns(host_clock) or something like that. The problem is that the clock names are impossible to remember. :)

However, making it clear from the name whether get_clock refers to the host_clock or rt_clock can be a useful cleanup.

The patches also make the frequency explicit (adds
qemu_htime_freq and qemu_vtime_freq).

The frequency of the clocks is now always explicit in the function names (using _ns or _ms).

The routines in qemu-timer should be already moved into the corresponding
qemu-*time files (I no longer remember on which state I left it), but the
routine name sanitizing is not finished, mostly because I still had to clear out
some details about how the current deadline calculation works.

I think after my series there is already a similar split, with qemu-timer.c doing everything except the guest clock, and cpus.c taking care of the guest clock.

I have a few more cleanups pending in this area, but I'll submit them probably after 1.0 since I have enough stuff on my plate already.

Does this kind of refactoring sound interesting?

Renaming the host_clock and rt_clock to something more easily remembered is trivial, but still useful.

It is also useful to make a dummy vmclock (with primitives like "get", "set", "advance to the next deadline") available outside qemu proper for use in unit tests. I'm not sure how close we are to unit testing of device models, but anything that makes us closer is worthwhile.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]