|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration |
Date: | Wed, 09 Sep 2009 12:59:20 -0500 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
Jan Kiszka wrote:
Anthony Liguori wrote:You get most of this pretty cheaply with qdev conversion. If you give the rtc a default id, you can tweak all of the properties with the -set command line option. It also provides a mechanism to change the default properties between machine types/versions which is ideal as we can introduce a kvm-specific machine type where we enable some of these things by default.Hmm, the refactoring of the old command line switches to -rtc is, if I understand qdev and -set correctly, widely orthogonal.
No, it isn't. To introduce -rtc properly, you should use QemuOpts. We shouldn't be introducing new options that don't conform to QemuOpts syntax and the best way to do that is to just use QemuOpts.
To communicate the QemuOpts to the rtc, I think the easiest approach is to convert rtc to qdev and reuse the -device logic. Otherwise, you have to use statics or add new parameters to the machine init.
Or is the policy now to freeze all command line switches in favor of the -device and -set?.
As much as possible, yes, I think this is the reasonable thing to do.
Hard to say. Doesn't the rtc keep track of wallclock time even on power off? I think using host_clock unconditionally does actually make sense.However, I will look into qdev conversion of the PC RTC. Besides the interface thing, I'm also interesting in comments on the other core idea, the selectable RTC base clock. Do we want this knob? Do we want host_clock unconditionally? Or should the other RTC that currently use the host time already also gain vm_clock support over the time?
-- Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |