Messages in this thread | | | Date | Thu, 1 Sep 2005 14:55:34 +0200 (CEST) | From | Roman Zippel <> | Subject | RE: 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/
| |