lkml.org 
[lkml]   [2004]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] CPU time clock support in clock_* syscalls
> Is there a standard for that? Or is it an opaque type that you have
> defined this way?

Of course there is no standard for the bits used in a clockid_t. This is
an implementation detail in POSIX terms. POSIX defines function interfaces
to return clockid_t values (clock_getcpuclockid, pthread_getcpuclockid).
I have chosen the kernel-user ABI for Linux clockid_t's here, but that is
only of concern to the kernel and glibc.

> Posix only defines a process and a thread clock. This is much more.

Like I said the first time, it's three kinds of clocks. One is what we
will in future use to define POSIX's CPUTIME clocks in our POSIX
implementation, and the other two are what we already use to define
ITIMER_REAL/ITIMER_VIRTUAL in our existing POSIX implementation.

> I wonder how glibc will realize access to special timer hardware. Will
> glibc be able load device drivers for timer chips?

glibc has zero interest in doing any of that. It will use the single new
"best information" kernel interface when that is available, and it's the
kernel's concern what the best information available from the hardware is.



Thanks,
Roland
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.079 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site