RE: FW: [RFC] A more general timeout specification

[Roman Zippel <zippel@linux-m68k.org>]

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/