Date: Sat, 26 Jul 2014 17:00:18 +0100 From: Mindaugas Rasiukevicius <[email protected]>
Not against the idea, but frankly - the implementation looks somewhat over-engineered. Most of the engineering in the implementation went into satisfying the request you made in private to limit the number of kthreads involved. I could make a much simpler implementation that does not pool kthreads, but you objected to that. Why not to extend the workqueue(9) interface in the first place? workqueue(9) is more fiddly than most users of it want. Half of what I hear about workqueues is `argh, why are they so painful to use?'. I don't hear that about usb_task(9), which is basically a specialization of task(9). However, usb_task(9) needs some help: e.g., usb_rem_task doesn't to wait for a task to complete and there's no way to do that. Plus as implemented it doesn't scale, and there's no reason for it to be specific to the USB stack. I surveyed all the users of workqueue(9) in-tree and found that the vast majority involve a workqueue for a single purpose with a single associated struct work, while some (e.g., ffs TRIM support) have a bunch of extra support code to drain their workqueue, and others (e.g., bcm53xx_eth) use both workqueues and softints only to adjust scheduling priorities and for no other obvious reason. All of these uses are more easily and more scalably served by task(9).
