On Thu 2009-12-10 21:37:59, Alexey Starikovskiy wrote: > Pavel Machek ??????????: > > On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote: > > > >> Hi Pavel, > >> > >> Please elaborate... Your comments "ugly as hell" are too often to be > >> specific... > >> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the > >> ACPICA code, > >> which we all agreed to keep OS independent, thus the need for #define. > >> Do you see any other way to add preemption point without introducing > >> Linux-specific > >> code into ACPICA? > >> > > > > I believe we want linux-specific code in acpica at this point. > > > > > The point there we call cond_resched() in ACPICA is an interpreter parse > loop. This parse loop may be executed from within atomic context and even > with interrupts off. In this case, cond_resched() should not be called > to not make > might_sleep() guards angry. Yes, so pass explicit argument to the interpretter, telling it what kind of context it runs on. Similar to kmalloc's GFP_KERNEL vs. GFP_ATOMIC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
