On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote: > yeah. There's some practical problems that need to be sorted out: much > of the current GTOD code is irq-driven (and all GTOD locks are > irq-safe), while the sysfs code needs to run in process-context level. > > Clocksources 'arrive' and 'depart' in hardirq context (which is the > primary place where we notice their breakage, determine that they are > now verified to be usable, etc.). This came partly from legacy: the > gradual conversion of the monolithic time code, and the need to preserve > GTOD and non-GTOD architectures without too much duplication. It also > came partly because there's also a fundamental need to have accurate > time, which is better served from irq context. > Is this in reference to the irq-context clocksource polling stuff? I don't see a dire reason to keep that code, and I agree removing that is a certainly a worth while cleanup .. I added this cleanup to one of my trees when you first suggested it , and there is some infrastructure that really should be added to facilitate it. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
