>From: Roman Zippel [mailto:[email protected]]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Hmm, I cannot think of more ways to specify a timeout than how
>> long I want to wait (relative) or until when (absolute) and which
>> is the reference clock. And they don't seem broken to me, common
>> sense, in any case. Do you have any examples?
>
>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.
[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].
>> Different versions of the same function that do relative, absolute.
>> If I keep going that way, the reason becomes:
>>
>> sys_mutex_lock
>> sys_mutex_lock_timed_relative_clock_realtime
>> sys_mutex_lock_timed_absolute_clock_realtime
>> sys_mutex_lock_timed_relative_clock_monotonic
>> sys_mutex_lock_timed_absolute_clock_monotonic
>> sys_mutex_lock_timed_relative_clock_monotonic_highres
>> sys_mutex_lock_timed_absolute_clock_monotonic_highres
>
>Hiding it behind an API makes it better?
It certainly cuts out cruft and to my not-so-trained eye, makes it
cleaner and easier to maintain.
>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.
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.
-- Inaky
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