linux-toradex.git/arch/um/os-Linux/time.c, branch v3.17

nohz: Rename CONFIG_NO_HZ to CONFIG_NO_HZ_COMMON

2013-04-03T11:56:03+00:00

We are planning to convert the dynticks Kconfig options layout
into a choice menu. The user must be able to easily pick
any of the following implementations: constant periodic tick,
idle dynticks, full dynticks.

As this implies a mutual exclusion, the two dynticks implementions
need to converge on the selection of a common Kconfig option in order
to ease the sharing of a common infrastructure.

It would thus seem pretty natural to reuse CONFIG_NO_HZ to
that end. It already implements all the idle dynticks code
and the full dynticks depends on all that code for now.
So ideally the choice menu would propose CONFIG_NO_HZ_IDLE and
CONFIG_NO_HZ_EXTENDED then both would select CONFIG_NO_HZ.

On the other hand we want to stay backward compatible: if
CONFIG_NO_HZ is set in an older config file, we want to
enable CONFIG_NO_HZ_IDLE by default.

But we can't afford both at the same time or we run into
a circular dependency:

1) CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED both select
   CONFIG_NO_HZ
2) If CONFIG_NO_HZ is set, we default to CONFIG_NO_HZ_IDLE

We might be able to support that from Kconfig/Kbuild but it
may not be wise to introduce such a confusing behaviour.

So to solve this, create a new CONFIG_NO_HZ_COMMON option
which gathers the common code between idle and full dynticks
(that common code for now is simply the idle dynticks code)
and select it from their referring Kconfig.

Then we'll later create CONFIG_NO_HZ_IDLE and map CONFIG_NO_HZ
to it for backward compatibility.

Signed-off-by: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Chris Metcalf 
Cc: Christoph Lameter 
Cc: Geoff Levand 
Cc: Gilad Ben Yossef 
Cc: Hakan Akkan 
Cc: Ingo Molnar 
Cc: Kevin Hilman 
Cc: Li Zhong 
Cc: Namhyung Kim 
Cc: Paul E. McKenney 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner

um: get rid of pointless include "..." where include <...> will do

2012-10-09T20:28:45+00:00

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger

uml: fix compile error in deliver_alarm()

2012-09-06T02:40:59+00:00

Fix the following compile error on UML.

  arch/um/os-Linux/time.c: In function 'deliver_alarm':
  arch/um/os-Linux/time.c:117:3: error: too few arguments to function 'alarm_handler'
  arch/um/os-Linux/internal.h:1:6: note: declared here

The error was introduced by commit d3c1cfcd ("um: pass siginfo to guest
process") in 3.6-rc1.

Signed-off-by: Miklos Szeredi 
CC: Martin Pärtel 
Signed-off-by: Linus Torvalds

um: pass siginfo to guest process

2012-08-01T22:49:17+00:00

UML guest processes now get correct siginfo_t for SIGTRAP, SIGFPE,
SIGILL and SIGBUS. Specifically, si_addr and si_code are now correct
where previously they were si_addr = NULL and si_code = 128.

Signed-off-by: Martin Pärtel 
Signed-off-by: Richard Weinberger

um: start switching the references to host mcontext_t to its userland type

2011-11-02T13:14:59+00:00

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger

um: -include user.h for USER_OBJ, trim includes

2011-11-02T13:14:44+00:00

Signed-off-by: Al Viro 
Signed-off-by: Richard Weinberger

um: fix global timer issue when using CONFIG_NO_HZ

2010-10-26T23:52:03+00:00

This fixes a issue which was introduced by fe2cc53e ("uml: track and make
up lost ticks").

timeval_to_ns() returns long long and not int.  Due to that UML's timer
did not work properlt and caused timer freezes.

Signed-off-by: Richard Weinberger 
Acked-by: Pekka Enberg 
Cc: Jeff Dike 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

uml: deal with host time going backwards

2008-06-06T18:29:10+00:00

Protection against the host's time going backwards (eg, ntp activity on
the host) by keeping track of the time at the last tick and if it's
greater than the current time, keep time stopped until the host catches
up.

Cc: Nix 
Signed-off-by: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

uml: track and make up lost ticks

2008-05-13T15:02:22+00:00

Alarm delivery could be noticably late in the !CONFIG_NOHZ case because lost
ticks weren't being taken into account.  This is now treated more carefully,
with the time between ticks being calculated and the appropriate number of
ticks delivered to the timekeeping system.

Cc: Nix 
Signed-off-by: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

uml: after_sleep_interval should return something

2007-12-03T16:13:17+00:00

I forgot to have an int-returning function actually return something.

Signed-off-by: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds