|| ||Thomas Gleixner <email@example.com>|
|| ||[patch 00/43] ktimer reworked|
|| ||Thu, 01 Dec 2005 00:56:58 +0100|
|| ||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
this patch series is a refactored version of the ktimer-subsystem patch.
firstly, we fixed two bugs noticed by Roman Zippel (and mentioned in the
- clock_nanosleep(): interrupted absolute sleeps are now handled
- overrun accounting in posix interval timers is fixed.
furthermore, we have split the ktimer patch series up into 23 patches -
each stage introduces one new (and mostly small) conceptual step. Each
stage builds & boots fine. The ktimer design has not been changed
radically, but some improvements and reshaping has been done in the
course of the rework.
based on the idea from Roman Zippel, we have eliminated the 'pure scalar
type' in ktime.h, and have gone for the ktime union for both 32-bit and
64-bit platforms. This resulted in further simplifications, e.g. the
ktime_cmp() ugliness has been removed.
to address the naming debate: we do agree that 'struct ktimer' and
'struct timer_list' is confusing and awkward - both are about timers.
Same goes for kernel/ktimer.c and kernel/timer.c.
but what we'd like to achieve as an end-result is the clear separation
of 'timer' vs. 'timeout' APIs. Our proposed end result would be to have
'struct ktimer' for timers, and 'struct ktimeout' for timeouts.
to prove the feasibility of this separation, we have also included
another 20 patches ontop of the ktimer patch-queue, which patches
introduce the 'ktimeout' types and APIs. This is mostly a careful
renaming and refactoring of the current 'struct timer_list' and APIs
into a 'struct ktimeout' object and API. (see the patches for details)
These patches too build & boot at every stage.
we have done this to show that the 'ktimer' vs. 'timer_list' confusion
is only temporary, and that the intended end-result is 'struct ktimer'
and 'struct ktimeout' - two separate concepts.
on the other hand, 'struct ptimer' and 'struct ktimeout' [or 'struct
ptimer' and 'struct timer_list'] would be just as confusing.
here's a list of other differences to the ptimer patchqueue:
- ptimer.c is smaller, for the price of making users of the APIs more
complex. ktimer.c carries more features and thus more code, so that
users can have simpler code.
these features are not unconditional: we tried to be careful to not
let 'cruft' creep into ktimer.c: e.g. quite some Posix 'special timer
code' is still kept in posix-timers.c.
Right now the extra code in ktimer.c is roughly offset by the code
reduction in posix-timers.c, itimer.c and timer.c/ktimeout.c, and we
have not converted posix-cpu-timers to ktimers yet. So we believe this
choice of us is a net win, even with the relative low number of
ktimer users at this early stage.
- the ktimer subsystem is designed with the extensibility for high
resolution timers and dynamic ticks in mind, without having to do
further rewrites. The practical feasibility and cleanliness of the
ktimer approach has been proven since the very beginning, both the
-khrt and the -rt trees have carried those patches for months now,
with a real HRT implementation ontop of it. We believe that some
details that the ptimers patch-queue chopped off the ktimers codebase
will have to be reintroduced for HRT timers later on.
- the resolution handling is implemented without any jiffy relations and
resembles the behaviour of the current implementation. The first view
of more complexity has to be carefully weighed against the flexibility
for further extensions.
- ktimer is fully docbook documented and well commented. The ptimer
patchqueue was based off an older ktimer tree with less comments and
if there are any other substantial differences between the ptimer
patchqueue and the current ktimer queue then please speak up. (there
was no documentation of all ktimer->ptimer changes, so we might have
the patchset has been compiled & booted against recent -linus trees, on
x86 and x64.
The patch series is also available from
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/