Hello.
Paul Mackerras wrote:
Tony started from an earlier patch by John Stultz, not from your
patches.
Well, that I can believe, yet the clockevents patch has traces of my
former work, and looking at read_persisitent_time() it looks suspiciously
close to my version too...
There is basically only one reasonably way to do a lot of this stuff.
The main reason your patches were rejected were that you completely
broke the VDSO and the deterministic time accounting, and made no
That's just not true!
They didn't broke vDSO (to be precise it was John's patch that broke it),
they just removed the vDSO code known to already be broken by -rt patch for
several months by then. And they didn't broke determinictic accounting --
they just made two things mutually exclusive. I haven't yet seen how the
patches that were preferred dealt with it at all.
OK. My requirement was that the clocksource/clockevent stuff and the
VDSO were both functional. Your patch didn't meet that requirement.
Which of my patches? There were many, and only one of them dealing with
vDSO. That's reasonable to drop that patch but it's not reasonable to drop the
other ones, not directly connected to vDSO issue. One flaw doesn't make the
whole patchset bad.
And now you have incomplete read_persistent_clock() implementation for
example, god knows why it was preferred to mine -- well, it also implemented
update_persistent_clock() bit those functions haven't appeared at the same
time, so read_persistent_clock() was written by me in the .
Really? IMO, the harware does keep a constant interrupt rate better than
software.
Well, if you have actual numbers to back that up, show them to us.
I don't believe you would be able to measure any difference, and so I
prefer the simplicity of only implementing the one-shot mode.
Well, that's up to you. I take it you wouldn't accept a patch
implementing auto-reload mode?
Because you broke important features
That is *not true*.
And nobody had interest to fix them for months (quite strange if they're
so important) while I had neither time nor interest to deal with them anymore
having written the code that *did work*, and not only for me.
Well, this is the difference between having a hack that works for you,
Agreed, -rt is a patchset full of hacks. :-)
and having something that can go upstream into mainline.
It *went* upstream. Mainline wasn't my aim at that time.
Anyway, this discussion doesn't seem to be going anywhere. If there
are changes you want made, or any other specific concrete action you
There are. I'll have to send patches (it's not that I have time for this)
but this is surely the fastest way to get things fixed (if I don't get ignored
that is).
want anyone to do, say so. Otherwise stop whinging.
I just wanted the reasons clarified and got what I wanted -- as I thought,
the decision behind preferring patches was somewhat biased, nobody really
cared about code quality or just wasn't familiar with hrtimers enough to judge
on the code quality...
Paul.
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
