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 ------------------------------------------------------- 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
