On Feb 16 Chris Boot wrote:
> On 15/02/2012 19:21, Stefan Richter wrote:
> > On Feb 15 Chris Boot wrote:
> >> + sbp_workqueue = alloc_workqueue("firewire-sbp-target", WQ_UNBOUND, 0);
> >> + if (!sbp_workqueue) {
> >> + target_fabric_configfs_deregister(fabric);
> >> + return -ENOMEM;
> >> + }
> >
> > What are your specific requirements that you cannot use one of the
> > system-wide workqueues?
>
> Nothing specific, I just thought it was sensible to use your own
> workqueue if you put enough work into it. I'll switch to the system queues.
OK, good. These days you can throw almost any kind of work into the
system workqueues without negative effect on their other users, given you
keep the queue properties in mind which are listed in linux/workqueue.h.
There is also some info in Documentation/workqueue.txt. If that still
leaves any doubt, you could Cc: Tejun Hejo on questions on the workqueue
infrastructure and he will likely give a helpful hint.
BTW, the drivers/firewire/ subsystem uses an own workqueue instead of the
system-wide ones because of combined requirements of non-reentrance and
memory-reclaim safety, explained in the changelog of commit 6ea9e7bbfc38.
--
Stefan Richter
-=====-===-- --=- =----
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
