[PATCH v2 3/4] Implement clockevents driver for powerpc

[Sergei Shtylyov]

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