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

_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers