lkml.org 
[lkml]   [2005]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: FW: [RFC] A more general timeout specification
Hi,

On Thu, 1 Sep 2005, Perez-Gonzalez, Inaky wrote:

> >You still didn't explain what's the point in choosing different clock
> >sources for a _timeout_.
>
> The same reasons that compel to have CLOCK_REALTIME or
> CLOCK_MONOTONIC, for example. Or the need to time out on a
> high resolution clock.
>
> A certain application might have a need for a 10ms timeout,
> but another one might have it on 100us--modern CPUs make that
> more than possible. The precission of your time source permeates
> to the precission of your timeout.

Please give me a realistic and non-broken example.
We can add lots of stuff to the kernel, because it _might_ be needed, but
we (usually) don't if it hurts the general case, just adds bloat and
userspace can achieve the same thing via different means.

> [of course, now at the end it is still kernel time, but the
> ongoing revamp work on timers will change some of that, one
> way or another].

That doesn't mean it has to be exported via every single kernel API, which
allows to specify a time.

> >You didn't answer my other question, let's assume we add such a timeout
> >structure, what's wrong with converting it to kernel time (which would
> >automatically validate it).
>
> And again, that's what at the end this API is doing, convering it to
> kernel time.

No, it's not doing this at the validation point.

> Give it a more "human" specification (timespec) and gets the job done.
> No need to care on how long a jiffy is today in this system, no need
> to replicate endlessly the conversion code, which happens to be
> non-trivial (for the absolute time case--but still way more trivial
> than userspace asking the kernel for the time, computing a relative
> shift and dealing with the skews that preemption at a Murphy moment
> could cause).
>
> It is mostly the same as schedule_timeout(), but it takes the sleep
> time in a more general format. As every other API, it is designed so
> that the caller doesn't need to care or know about the gory details
> on how it has to be converted.

Sorry, but I don't get what you're talking about. What has the user space
concept of time to do with how the kernel finally handles a timeout?
More specifically why does the first require a new API in the kernel to
deal with all kinds of timeouts?

bye, Roman
-
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-09-01 14:58    [W:0.307 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site