Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIXclock_* syscalls

[Roland McGrath]

> Sounds good.

I'm glad you like it.  Your prior interest and work in this area stimulated
general interest and active discussion, and I think that has contributed to
the likelihood of getting useful functionality available to users ASAP.

> This yields some additional functionality and is an improvement to the
> ABI. Why is CLOCK_*_CPUTIME_ID etc not directly supporting using
> the kernel API? Otherwise the API will take only some of the posix
> clocks defined in the kernel which may surprise authors of other c
> libraries.

It's mainly just to simplify the code.  The CPU clocks did not quite fit
into the k_clock function-table model, though I think that was really the
case more before some k_clock interface cleanups happened.  Now I think it
might be possible to write k_clock hook functions that call into the
posix_cpu_* functions for those small-integer constant clockid_t cases,
though off hand what I would be more confident of would be to handle them
in the existing special case calls.  i.e., if they are supported at all it
might best be by having every call translate CLOCK_*_CPUTIME_ID to
MAKE_*_CPUCLOCK(SCHED, 0) before the < 0 check.  I really don't see the
need to support those values in the kernel interface, which never did
before (though having them in linux/time.h).  But I would not object to it.
I just strongly doubt anyone would ever use it.

> It seems that this code does now support extra clocks like
> CLOCK_REALTIME_HR, CLOCK_MONOTONIC_HR and CLOCK_SGI_CYCLE right?

Here I think you are talking about glibc, not kernel code.  If you mean
this about the kernel code, then please clarify (and I'm not sure what the
question means in that context).  If you are asking about the glibc code,
please take that to the libc mailing list and we won't bother the kernel
folks with that discussion.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/