Please, when sending patches, attach them. This avoids problems with mailers,
on both ends, messing with white space. They still appear in line, at least in
some mailers (mozilla in my case).
The custom on lkml, for Linus and Andrew is to send them inline. I also
prefer them inline. Will try to remember sending attachments when sending a
patch to you.
As to the test program, what happens when you attempt to set up a timer on these
clocks? (No, I don't think it should work, but we DO want to properly error
out. And the test should verify that this happens.) By the way, if you use the
support package from sourceforge, you will find a lot of test harness stuff.
That is an interesting issue. If that would work correctly one could
trigger an signal if more than a certain amount of cputime is used.
It looks though that it will create an interrupt based on real time.
SuS says:
Each implementation defines a set of clocks that can be used as timing
bases for per-process timers. All implementations support a clock_id of
CLOCK_REALTIME.
So restrict timer_create to CLOCK_REALTIME and CLOCK_MONOTONIC? Is it
necessary to be able to derive a timer from a timer derives from those
two?
something like the following (just inlined for the discussion ...)?
--- linux-2.6.9-rc2.orig/kernel/posix-timers.c 2004-09-28 20:29:28.000000000 -0700
+++ linux-2.6.9-rc2/kernel/posix-timers.c 2004-09-29 11:12:37.814713085 -0700
@@ -585,8 +585,8 @@
sigevent_t event;
int it_id_set = IT_ID_NOT_SET;
- if ((unsigned) which_clock >= MAX_CLOCKS ||
- !posix_clocks[which_clock].res)
+ if ((unsigned) which_clock != CLOCK_REALTIME &&
+ (unsigned) which_clock != CLOCK_MONOTONIC)
return -EINVAL;
new_timer = alloc_posix_timer();