See my recent (lengthy) posts on this subject.
> > > The num is xor:d with the value from 2 timer registers,
> > > which in turn contains different fields breifly described below.
> > >
> > > Does the patch below look sane?
> >
> > Looks fine, but I think we want to come up with a cleaner scheme of
> > having per-arch high-res timestamps. I'd hate to have that grow to
> > several pages of ifdefs and not have it available anywhere else.
>
> Yes, I've seen the discussion before.
> Any idea of how such a solution should look like?
> Put an inline function or macro in asm/timex.h (?) together with an
> ARCH_HAS_RANDOM_TIMESTAMP define?
I don't think we want to make it specific to random. I think we just
want to call it hires.
> E.g. like this for i386:
> #define ARCH_HAS_RANDOM_TIMESTAMP
> #define RANDOM_TIMESTAMP(time, num) do{\
> if ( test_bit(X86_FEATURE_TSC, &boot_cpu_data.x86_capability) ) { \
> __u32 high; \
> rdtsc(time, high); \
> num ^= high; \
> } else { \
> time = jiffies; \
> } \
> }while(0)
>
> And then in random.c:
> ifdef ARCH_HAS_RANDOM_TIMESTAMP
> RANDOM_TIMESTAMP(time, num);
> #else
> time = jiffies;
> #endif
Again, too random-specific. And we need a way to get the timescale.
Perhaps something like:
speed=get_timestamp_khz;
lowbits=get_hires_timestamp();
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/