[lkml]   [2005]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

On Wed, 10 Aug 2005, john stultz wrote:

> Here's the next rev in my rework of the current timekeeping subsystem.
> No major changes, only some cleanups and further splitting the larger
> patches into smaller ones.
> The goal of this patch set is to provide a simplified and streamlined
> common timekeeping infrastructure that architectures can optionally use
> to avoid duplicating code with other architectures.

It's still the same old abstraction. Let's try it in OO terms why it's the
wrong one. What basically is needed is something like this:

base clock -> continuous clock -> clock implemention
-> tick clock -> ....

The base clock class is an abstract class which provides the basic time
services like get time, set time...
The continuous clock class and tick clock class are also abstract classes,
but provide basic template functions, which can be used by the actual
implementations do most of the work.

What you do with your patches is to just provide an abstract class for
continous clocks and tick based clocks have to emulate a continuous clock.
Please provide the right abstractions, e.g. leave the gettimeofday
implementation to the timesource and use some helper (template) functions
to do the actual work. Basically as long as you have a cycle_t in the
common code something is really wrong, this code belongs in the continous
clock template.

This also allows better implementations, e.g. gettimeofday can be done in
a single step instead of two using a single lock instead of two.

bye, Roman
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-16 00:16    [W:0.206 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site