Dean - On Tue, 17 Apr 2012, Dean Jenkins wrote:
Hi, I am interested to the understand the design decisions for changing from tasklets to workqueues. Was there a fundamental flaw that necessitated the change ? I am asking because I am getting a Bluetooth "scheduling while atomic" failure on an ARM based 2.6.34 kernel (with some 2.6.37 Bluez backports). Changing to workqueues would avoid this issue as a workqueue use process context that can sleep. Thanks for any info on the design decisions.
Take a look at http://article.gmane.org/gmane.linux.bluez.kernel/19535 and the thread it is part of. The main motivation was to eliminate bugs and complexity arising from a mix of tasklet-context and process-context code. Locking and concurrency problems have become trickier with the introduction of the management interface, L2CAP ERTM, and AMP.
There were big changes to the workqueue internals in 2.6.36, I don't know if that will cause major issues when backporting current code to 2.6.34.
-- Mat Martineau Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
