lkml.org 
[lkml]   [2004]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIX clock_* syscalls
On Tue, 14 Dec 2004, Roland McGrath wrote:

> > 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.

I just reviewed the glibc patches and the kernel side and I would think
that your glibc code would be simplified by passing all CLOCK_* values
straight through and then calling your cputimer functions as needed in
the kernel as before. As also said before this would also make the
interface more intuitive and keep the existing semantics for clock_id's >
0. It would separate the most common use from the special functionality
intended for access to clocks of other processes/threads/(whatever you
want to call them).

The glibc side already is a mess and I would think that doing so
also would keep things cleaner on that side.

Also

Why are the hooks in sys_gettime and not in do_gettime? Is there any
reason that the existing user space transfer code in do_gettime not be
used? I would like to have all user space interfacing centralized in
posix-timers.c. clock specific code should not deal with user space
pointers. Do not merge do_clock_gettime and sys_clock_gettime.

posix-cpu-timers.c needs to have all user space interaction removed. If
you would like to make improvements to the code transferring to / from
user space them make them for the general case in posix-timers.c.

Ideally the integration of the cpu timers into posix-timers.c would
follow the general way that clock specific code is called as closely as
possible.
-
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:08    [from the cache]
©2003-2011 Jasper Spaans