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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
