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

Re: [Xen-devel] [PATCH] Have xen dom0 still handle time of 1970

  • To: Steven Rostedt <srostedt@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 17 Jan 2007 17:26:12 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 17 Jan 2007 09:25:48 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acc6XJVT0+xHBKZPEduIGwAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] Have xen dom0 still handle time of 1970

On 17/1/07 16:30, "Steven Rostedt" <srostedt@xxxxxxxxxx> wrote:

> Have a box with Xen running more than a day? (I currently don't), and if
> you do, try the above date command. You'll see what I'm talking about.
> The example is bad, but I didn't have a machine to show that has been
> running a Xen kernel for more than an hour or two.

Oh, I see. But it kind of feels silly to work around a synthetic correctness
test. If we make wc_sec implicitly signed (which is pretty gross) then we
lose 1 bit of magnitude which also isn't great -- I'd rather be able to
represent years 2038 through 2106 than 1902 through 1970.

What we could do, to keep LTP happy, is set the local domain's time as
specified but clamp the time sent to Xen at epoch+uptime. This would require
dom0 to read wc_time from Xen only once at boot. OTOH perhaps we just do not
really care -- after all by default this LTP test will fail on all domU
because settimeofday() is a no-op unless /proc/sys/xen/independent_wallclock
is asserted. And if you set that flag on dom0, the LTP test will magically
start working there too! :-)

Perhaps at least we should fail or clamp the settimeofday() call, rather
than doing some mad warp into the future...

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.