Re: Linux 2.6.16-rc3

[Russell King <rmk+lkml@arm.linux.org.uk>]

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