Il 30/06/2014 21:53, Lb peace ha scritto:
If you use hwclock in guest os ,you will find the result of hwclock
isn't changed after changing host os's clock.
I find this issue is generated in this patch:
http://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03353.html
Before this patch,the resul
On Tue, Jul 01, 2014 at 03:53:08AM +0800, Lb peace wrote:
> If you use hwclock in guest os ,you will find the result of hwclock isn't
> changed after changing host os's clock.
> I find this issue is generated in this patch:
>
> http://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03353.html
> B
On 1 Jul 2014, at 02:12, Lb peace wrote:
> 1)“ it's an automated output of perl simply changing one calling convention
> to another”.What do you mean... I
> can not find the point :)
I'd thought this was the huge patch which was generated by
perl to change the API, but it's not.
> 2) The pro
1)“ it's an automated output of perl simply changing one calling convention
to another”.What do you mean... I
can not find the point :)
2) The problem is :
a.use QEMU to run linux-0.2.img with command qemu-system-i386
linux-0.2.img or sth. like that
b.hwclock ,and we get a date1(2014-07
On 30 Jun 2014, at 20:53, Lb peace wrote:
> If you use hwclock in guest os ,you will find the result of hwclock isn't
> changed after changing host os's clock.
> I find this issue is generated in this patch:
I find it hard to believe that the patch you mention is the problem,
as it's an autom
If you use hwclock in guest os ,you will find the result of hwclock isn't
changed after changing host os's clock.
I find this issue is generated in this patch:
http://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03353.html
Before this patch,the result will be changed if you change host's clock
