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. - 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
