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
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
