>From: Roman Zippel [mailto:[EMAIL PROTECTED] >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 specification >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 time >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 [mailto:[EMAIL PROTECTED] >... >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: 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 s/mutex_lock/ with whatever system call that takes a timeout you want and 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/