[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: FW: [RFC] A more general timeout specification
>From: Roman Zippel []
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>> I cannot produce (top of my head) any other POSIX API calls that
>> allow you to specify another clock source, but they are there,
>> somewhere. If I am to introduce a new API, I better make it
>> flexible enough so that other subsystems can use it for more stuff
>> other than...
>So we have to deal at kernel level with every broken timeout
>that comes along?

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?

In any case, like it or not, POSIX is what almost every application
uses to talk to the kernel.

>> ...adding more versions that add complexity and duplicate
>> code in many different places (user-to-kernel copy, syscall entry
>> points, timespec validation). And the minute you add a clock_id
>> you can steal some bits for specifying absolute/relative (or vice
>> versa), so it is almost a win-win situarion.
>What "more versions" are you talking about? When you convert a user
>to kernel time you can automatically validate it and later you can use
>standard kernel APIs, so you don't have to add even more API bloat.

The versions you were talking about:

>From: Roman Zippel []
>Why is not sufficient to just add a relative/absolute version,
>which convert the time at entry to kernel time?

Different versions of the same function that do relative, absolute.
If I keep going that way, the reason becomes:


s/mutex_lock/ with whatever system call that takes a timeout you want
keep adding combinations. On each of those check for validity of the
__user pointer, copy it, validate the timespec.

[admitedly I am stretching the point with the different clock types].

So where is the problem on unifying all that handling? You are still
not offering any constructive criticism to solve the issue that now
the syscalls take relative timeouts vs the absolutes we need.

-- Inaky
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-01 02:03    [W:0.084 / U:0.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site