Messages in this thread | | | Date | Wed, 11 Jul 2007 19:42:52 +0200 | From | Ingo Molnar <> | Subject | Re: x86 status was Re: -mm merge plans for 2.6.23 |
| |
* Andi Kleen <andi@firstfloor.org> wrote:
> > clockevents-fix-typo-in-acpi_pmc.patch > > timekeeping-fixup-shadow-variable-argument.patch > > timerc-cleanup-recently-introduced-whitespace-damage.patch > > clockevents-remove-prototypes-of-removed-functions.patch > > clockevents-fix-resume-logic.patch > > clockevents-fix-device-replacement.patch > > tick-management-spread-timer-interrupt.patch > > highres-improve-debug-output.patch > > hrtimer-speedup-hrtimer_enqueue.patch > > pcspkr-use-the-global-pit-lock.patch > > ntp-move-the-cmos-update-code-into-ntpc.patch > > i386-pit-stop-only-when-in-periodic-or-oneshot-mode.patch > > i386-remove-volatile-in-apicc.patch > > i386-hpet-assumes-boot-cpu-is-0.patch > > i386-move-pit-function-declarations-and-constants-to-correct-header-file.patch > > x86_64-untangle-asm-hpeth-from-asm-timexh.patch > > x86_64-use-generic-cmos-update.patch > > x86_64-remove-dead-code-and-other-janitor-work-in-tscc.patch > > x86_64-fix-apic-typo.patch > > x86_64-convert-to-cleckevents.patch > > acpi-remove-the-useless-ifdef-code.patch > > x86_64-hpet-restore-vread.patch > > x86_64-restore-restore-nohpet-cmdline.patch > > x86_64-block-irq-balancing-for-timer.patch > > x86_64-prep-idle-loop-for-dynticks.patch > > x86_64-enable-high-resolution-timers-and-dynticks.patch > > x86_64-dynticks-disable-hpet_id_legsup-hpets.patch > > I'm sceptical about the dynticks code. It just rips out the x86-64 > timing code completely, which needs a lot more review and testing. > Probably not .23
What you just did here is a slap in the face to a lot of contributors who worked hard on this code :(
Let me tell you about the history of this project first. Arjan wrote the first version of it a year ago, and it was added to -rt and tested there by many people and went through many iterations and fixes. Chris Wright then created a x86_64 clockevents cleanup and dynticks enabling patchset from it this spring and sent it to lkml three and a half months ago, on March 31:
http://lwn.net/Articles/229094/
Thomas, the high resolution timers and clockevents maintainer, immediately picked up Chris' splitup/splitout/cleanup work and fixed and extended it, and sent a first cut to lkml on May 6th:
http://lwn.net/Articles/233226/
Thomas then sent an updated version of the x86_64 clockevents cleanup and dynticks code to lkml (on June 10th), for a second round of review:
http://lwn.net/Articles/237687/
As Thomas stated it in his submission:
" The patch set has been tested in the -hrt and -rt trees for quite a while and the initial problems have been sorted out. Thanks to the folks from the PowerTop project for testing and feedback. "
Then on June 16th Thomas sent the third series:
http://lwn.net/Articles/238834/
(which too was in -rt and was tested there on numerous machines. It was also added to -mm.)
Then on June 23rd Thomas sent the fourth series of the x86_64 clockevents and dynticks code:
http://lwn.net/Articles/239620/
We finally have someone (Thomas) with core kernel clue who actually _cares_ about the x86 time code and does not see it as an ugly chore, one who collects the right patches and maintains the -hrt tree and co-maintains the -rt tree and interacts with other contributors. What he did was _hard_ to do but we are making really good progress:
http://lkml.org/lkml/2007/7/5/242
" All in all, personally I'm very happy to see Linux making such a huge step forward with tickless and can't wait for this step to be available in all distros and for all architectures... "
Yes, touching the time code is a pain because both the hardware and the kernel has skeletons hidden in the closet, but we are mapping them one by one, and we already fixed several kernel skeletons in the process. The code is in -mm and there is no open regression related to this queue of patches at the moment.
But what is curiously absent from all this positive and dynamic activity around these patches on lkml? There is not a single email from Andi Kleen, the official maintainer of the x86_64 tree directly reacting to this submission in any way, shape or form. Not a single email from you thanking Arjan, Chris and Thomas for this amount of cleanup to the architecture you are maintaining:
31 files changed, 698 insertions(+), 1367 deletions(-)
Not a single email from you reviewing the patchset in any meaningful way. Not a single email from you to indicate that you even did so much as boot into this patchset.
What contribution do we have from you instead? A week before the .23 merge window is closed, in the very last possible moment, we finally get your first reaction to this patchset, albeit in the form of three terse sentences:
> I'm sceptical about the dynticks code. It just rips out the x86-64 > timing code completely, which needs a lot more review and testing. > Probably not .23
In the past 3+ months there was not a single email from you indicating that you are "doubtful" about this submission, and that you think that it needs "lot more review and testing". You dont offer any alternative, you dont offer any feedback, no review, no testing, no support, just a simple rejection on lkml that prevents this project from going upstream.
Yes, maintainers have veto power and often have to make hard decisions, but, and let me stress this properly:
Only if they actually act as honest maintainers!
Altogether 197 emails on lkml discussed these patches, and you were Cc:-ed to every one of them. Over a dozen kernel developers reviewed it or reacted to the patchset in one way or another. And your only reaction to this is silence and a rejection claiming that it needs "lot more review"? I'm utterly speechless.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |