Date: Tue, 5 Oct 2004 18:21:39 -0700 (PDT)
From: Christoph Lameter <clameter@sgi.com>
To: Roland McGrath <roland@redhat.com>
cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Ulrich Drepper <drepper@redhat.com>, jbarnes@sgi.com
Subject: Re: [PATCH] CPU time clock support in clock_* syscalls
In-Reply-To: <200410060035.i960Z1Iv007864@magilla.sf.frob.com>
Message-ID: <Pine.LNX.4.58.0410051809590.30594@schroedinger.engr.sgi.com>
References: <200410060035.i960Z1Iv007864@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2162
Lines: 52

On Tue, 5 Oct 2004, Roland McGrath wrote:

> > Maybe its best then to restrict this definition to glibc?
>
> I can't figure out what problem you think exists or what you are trying to
> gain here.

If clockid_t with your proposed bitfields would be restricted to glibc
alone then we would not have to deal with these bits on the kernel level.

The clock_gettime function calls would take a clock number, not a
clockid_t  in the way that you want to use it. That would allow us to keep
the interface clear of pids mixed with clock numbers.

> > How will you provide the necessary hardware interface for the kernel
> > clocks?
>
> You again seem to be asking a question that makes no sense in the context
> that I have already explained.

The question is pretty acute. Currently glibc accesses CPU timers on its
own bypassing the kernel. Most of the times it works but on lots of
systems this is royally screwed up and CLOCK_*_CPUTIME_ID returns funky
values.

User needs to be able to use the specialized clocks provided by the
kernel. Currently CLOCK_REALTIME and CLOCK_MONOTONIC are the only clocks
that glibc will use. It seems that some people have tried to convince the
glibc maintainers to allow more clocks (in particular CLOCK_REALTIME_HR
and CLOCK_REALTIME_HR). The current patch in mm provides for
CLOCK_SGI_CYCLE.

We have been trying to get a resolution on these issues for a long time
from the glibc folks (I can trace the CPUTIME issue back at least 1 1/2
years).

Would be possible to define a clean interface that would get glibc out of
the business of accessing hardware directly and allow some sanity in terms
of clock access?

Does this fit not into your context? I have stated the problem a gazillion
times, I probably have no problem in explaining it another ten times to you.

I do not see that you are solving the most urgent problems. Instead we get
funky forms of pid's mixed with clockid's.


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