Jeff Garzik wrote:
James Ketrenos wrote:Jeff Garzik wrote:James Ketrenos wrote:That said -- if the driver can execute in parallel to the stack for some operations, shouldn't they remain on their own workqueues so the work can be divided up vs. having *everything* routed through one singlethread workqueue?Just because it -can-, does not mean it should.Unless there is a -proven- need for the operations to be parallel, you should avoid the burden of such complexity.There is no additional complexity by having the driver create its own workqueue; it just calls create_workqueue during probe and destroy_workqueue during remove.That is obviously false. Ignoring the additional code and memory usage, you must additionally evaluate the potential for deadlocks and races.
So you're saying that by using mac80211's workqueue a driver no longer has to worry about any deadlocks or race conditions? That is obviously false.
And then there is the Linus mantra: do what you must, and no more. No need for additional workqueues has been demonstrated. (which I noticed your response completely skipped -- an implicit admission of lack of need)
Funny. I noticed you completely deleted the part of my original email that listed one reason why we can't just use mac80211's workqueue currently: "We need to have a workqueue for initializing the adapter and uCode before we call ieee80211_register_hw. If ieee80211_alloc_hw created the workqueue, that would work for us (assuming there aren't going to be any side effects from us flushing the workqueue before we call ieee80211_free_hw/ieee80211_unregister_hw) "I didn't say we can't use mac80211's workqueue if it was created/destroyed during alloc/free vs. hw register.
I asked a question about if work can execute in parallel, shouldn't we let it -- and you came back saying I have to prove a need to execute in parallel. I get your point -- Linux isn't about innovation, discussion, or putting code out and having it evolve and stand the test of time. Its about doing exhaustive experimentation in house, putting together a thesis, and then submitting it to the mailing list. I'll do my best to follow that model moving forward. Thanks, James
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
