Messages in this thread | | | Date | Thu, 16 Feb 2006 18:09:39 +0000 | From | Russell King <> | Subject | Re: Linux 2.6.16-rc3 |
| |
On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote: > On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote: > > This is probably an idiotic question, but if there's something in the > > scsi release handler can't be called in non-process context, why can't > > scsi queue up the release processing via the work API itself, rather > > than having to have this additional code and complexity for everyone? > > It's because, in order to get a guaranteed single allocation for the > workqueue to execute in user context, I need to know when the release > will be called. The only way to do that is to add the execute in > process context directly to kref_put.
Is there something in the driver model which would prevent something like this?
static void scsi_release_process(void *p) { struct my_work *work = p; struct device *dev = work->dev;
/* destroy dev */
kfree(work); }
static void scsi_release(struct device *dev) { struct my_work *work;
work = kmalloc(sizeof(struct my_work), GFP_ATOMIC); if (work) { INIT_WORK(&work->work, scsi_release_process, work); work->dev = dev; schedule_work(&work->work); } else { printk(KERN_ERR ...); } }
where scsi_release() is the function called by the device model on the last put of a scsi device.
I guess is more or less what you're trying to do invasively via the driver model.
-- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |