From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: "Peter T. Breuer" <ptb@inv.it.uc3m.es>
Cc: john stultz <johnstul@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: uptime increases during suspend
Date: Tue, 28 Mar 2006 00:30:27 +0200 [thread overview]
Message-ID: <44286783.9000709@tremplin-utc.net> (raw)
In-Reply-To: <200603271953.k2RJrTR28039@inv.it.uc3m.es>
27.03.2006 21:53, Peter T. Breuer wrote/a écrit:
> In article <1143484821.2168.16.camel@leatherman> you wrote:
>>> Would it be possible to get the old behaviour back?
>
>> Why exactly do you want this behavior? Maybe a better explanation would
>> help stir this discussion.
>
> I don't know why he wants it (uptime does not increase during
> hibernation) but I want it so that I can tell if I should time out or
> not on an alarm for inactivity in userspace! The alarm should fire if
> there has been no activity for a while (30s) while activity is possible.
> If the machine is suspended, no activity is possible, so the alarm
> should not fire.
>
> This is to counteract sysadamins playing with system time (e.g. syncing
> with a net time server after bootup) which might cause artificial time
> outs. Causing a timeout has nasty consequences when, for example, your
> root fs is mounted over the net via daemons that do the network to-ing
> and fro-ing from userspace. The only way they have of getting an
> estimate of REAL time elapsed, without admin playing about messing
> with them, is by surreptitiously snooping uptime, which more or less
> represents kernel jiffies.
It seems that what you are really looking for in your application is a
monotonic clock. Linux has such thing since few releases. Using
CLOCK_MONOTONIC (cf "man 3 clock_gettime") may look much less hacky than
using the uptime ;-)
Now... concerning the suspend effect on this clock, I don't know. It's
probably the same problem as uptime: no official semantic has ever been
stated yet... Does anyone know?
Eric
next prev parent reply other threads:[~2006-03-27 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-25 15:02 uptime increases during suspend Jonathan Black
2006-03-25 15:10 ` Rafael J. Wysocki
2006-03-25 15:18 ` Jonathan Black
2006-03-26 21:38 ` Rafael J. Wysocki
2006-03-27 18:40 ` john stultz
2006-03-27 19:53 ` Peter T. Breuer
2006-03-27 20:01 ` linux-os (Dick Johnson)
2006-03-27 22:30 ` Eric Piel [this message]
2006-03-28 3:57 ` Peter T. Breuer
2006-03-27 21:37 ` Tomasz Torcz
2006-03-27 22:43 ` Rafael J. Wysocki
2006-03-29 14:52 ` Jonathan Black
-- strict thread matches above, loose matches on Subject: below --
2006-03-28 2:01 Peter T. Breuer
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=44286783.9000709@tremplin-utc.net \
--to=eric.piel@tremplin-utc.net \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ptb@inv.it.uc3m.es \
/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.