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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo