|
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.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |