On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote: > On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote: > > Well, I can't solve the problem that it requires memory allocation from > > IRQ context to operate. Based on that, it's an unsafe interface. I'm > > going to put it inside SCSI for 2.6.16, since it's better than what we > > have now, but I don't think we can export it globally. > > OK, this is what I'm proposing as the device model fix. What it does is > thread context checking APIs throughout the device subsystem. SCSI can > then use it simply via device_put_process_context(). Since we have to > supply the kref_work; I'd plan to do that as an additional element in > struct scsi_device. > > This, by itself, won't solve the SCSI target problem, but I plan to fix > that via a device model addition which would have target alloc waiting > around for any deleted targets to disappear. > > Since this is planned for post 2.6.16, we have plenty of time to argue > about it. 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? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
