quoted

I guess you mean you *can* build it? Surely you're introducing the new
HR timer modes in some patch that I didn't see? :-)

Sorry, we did not want to expose you to 30 patches fiddling with the core
code. They are on LKML though.

Sure, no worries. I just didn't even realize I shouldn't be applying
the patch (myself) :-)

quoted

Right. Then again, why even pass it to init() and start()? Can you
start without going through start()?

There is a subtle magic with CLOCK_REALTIME timers.

CLOCK_REALTIME timers differentiate between ABS and REL modes. ABS timers
are exposed to clock modifications (settimeofday() ...), REL timers are
not. We solve that by associating them to different clock bases, which has
to be done at init time, but the start function needs the REL/ABS
information as well.

For CLOCK_MONOTONIC this is not really required, but the function is used
for all clock bases, so we require the mode bits for all.

Hmm. Couldn't you just store that then from init to use in start?

If you don't store it, yet don't verify that you passed the same 
thing, do you at least check that it's compatible? Sounds like
something will totally go wrong if I pass CLOCK_REALTIME/ABS first and
then use REL for start, or vice versa?

Also, in the code I see only checking

if (mode != HRTIMER_MODE_ABS) {
	// change clock ID:
	// realtime -> monotonic
	// realtime_soft -> monotonic_soft
}

but you're passing HRTIMER_MODE_ABS_SOFT too, isn't that considered an
ABS mode?

But then, looking at the code again, I don't even see
HRTIMER_MODE_ABS_SOFT existing, it sounds like it should be

hrtimer_init(..., CLOCK_REALTIME_SOFT, HRTIMER_MODE_REL);

then?

At least then the code I mentioned above makes sense, but it still
feels pretty dangerous to not just store the mode and use it in start,
but to require passing it again. You even just introduced the same bug,
it just happened to not matter in this case since the clock isn't
realtime.

Or am I completely confused now?

johannes