Sergei Shtylyov writes: > And now you have incomplete read_persistent_clock() implementation for
I don't see anything incomplete about it. If you do, feel free to post a patch. > example, god knows why it was preferred to mine -- well, it also implemented Your most recent post of your patch to implement read_persistent_clock was in May -- five months ago -- and you said this about it: "This patch hasn't received a good testing though". You don't have to be a god to figure out why I preferred a patch that had been tested, where the author was responding to comments and posting updated versions of his patch in the period leading up to the merge window, over that. > Well, that's up to you. I take it you wouldn't accept a patch > implementing auto-reload mode? I already told you. Show me numbers (real measurements showing that it's better) and I'll consider it. > 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). All of us only get stuff in by spending the time to develop patches and posting them for comment. 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... You really know how to persuade people to cooperate, don't you... :P Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
