On Thu, 14 Dec 2006, Eric W. Biederman wrote: > Actually I don't accept that a signal needs to be sent. I do accept > that the message needs to be delivered to stop things early. > > The paradigm in a kthread world for waking up kernel threads is by > calling kthread_stop, and then for testing if a kernel thread should > stop is by calling kthread_should_stop. > > Especially if you are looking at generalizing this code over all of > usb it should probably be using the current kernel best practices. > > There is still an issue with msleep here that I completely concede. > In particular neither msleep nor msleep interruptible will actually be > awoken by kthread_stop. So it looks like we need a msleep_kthread > that will won't go back to sleep if after kthread_stop wakes it up. > Still unless I am blind that looks like a very minor change from where > we are now. Something else to think about. I've got a driver that starts up a kernel thread which calls vfs_read() and vfs_write() and relies on signals to interrupt the I/O operations when necessary. Perhaps this approach is fundamentally wrong, but I'm not sure how else to do it. Alan Stern
