All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: John Stultz <john.stultz@linaro.org>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH RFC V1 0/5] Rationalize time keeping
Date: Thu, 3 May 2012 09:02:07 +0200	[thread overview]
Message-ID: <20120503070139.GA2235@netboy.at.omicron.at> (raw)
In-Reply-To: <4F9EFC70.50405@linaro.org>

On Mon, Apr 30, 2012 at 01:56:16PM -0700, John Stultz wrote:
> No. So, on architectures that support vsyscalls/vdso (x86_64,
> powerpc, ia64, and maybe a few others) getnstimeofday() is really
> only an internal interface for in-kernel access. Userland uses the
> vsyscall/vdso interface to be able to read the time completely from
> userland context (with no syscall overhead). Since this is done in
> different ways for each architecture, you need to export the proper
> information out via update_vsyscall() and also update the
> arch-specific vsyscall gettimeofday paths (which is non-trivial, as
> some arches are implemented in asm, etc - my sympathies here, its a
> pain).

Okay, so now I understand the vDSO page thingy. Help me please to
understand exactly which architectures would need changes for my
proposal.

The only archs exporting time variables/functions through vDSO are
those which define CONFIG_GENERIC_TIME_VSYSCALL=y, namely:

- ia64
- powerpc 64 and 32 bit
- s390    64 and 32 bit
- x86     64 bit only **

  ** But 32 guest running in a 64 host also has time in the vDSO?!?

Did I get that right?

Thanks,
Richard



  parent reply	other threads:[~2012-05-03  7:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27  8:12 [PATCH RFC V1 0/5] Rationalize time keeping Richard Cochran
2012-04-27  8:12 ` [PATCH RFC V1 1/5] Add functions to convert continuous timescales to UTC Richard Cochran
2012-04-27  8:12 ` [PATCH RFC V1 2/5] ntp: Fix a stale comment and a few stray newlines Richard Cochran
2012-04-27 22:25   ` John Stultz
2012-04-27  8:12 ` [PATCH RFC V1 3/5] timekeeping: Fix a few minor newline issues Richard Cochran
2012-04-27 22:25   ` John Stultz
2012-04-27  8:12 ` [PATCH RFC V1 4/5] timekeeping: Offer an interface to manipulate leap seconds Richard Cochran
2012-04-27 23:08   ` John Stultz
2012-04-28  8:47     ` Richard Cochran
2012-05-05 10:17     ` Richard Cochran
2012-05-07 17:36       ` John Stultz
2012-04-27  8:12 ` [PATCH RFC V1 5/5] timekeeping: Use a continuous timescale to tell time Richard Cochran
2012-05-28 16:49   ` Richard Cochran
2012-04-27 22:49 ` [PATCH RFC V1 0/5] Rationalize time keeping John Stultz
2012-04-28  8:04   ` Richard Cochran
2012-04-30 20:56     ` John Stultz
2012-05-01  7:17       ` Richard Cochran
2012-05-01  8:01         ` John Stultz
2012-05-01 18:43           ` Richard Cochran
2012-05-03  7:02       ` Richard Cochran [this message]
2012-05-03 15:48         ` John Stultz
2012-05-03 18:21   ` Richard Cochran
2012-05-03 18:44     ` John Stultz
2012-05-03 19:28       ` Richard Cochran
2012-05-03 19:42         ` John Stultz
2012-05-03 19:57 ` John Stultz
2012-05-05  7:34   ` Richard Cochran
2012-05-05 19:25     ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120503070139.GA2235@netboy.at.omicron.at \
    --to=richardcochran@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.