Messages in this thread | | | Date | Wed, 9 Nov 2005 18:24:44 +0100 | From | Aritz Bastida <> | Subject | Re: Stopping Kernel Threads at module unload time |
| |
> > > Now, if I call kthread_stop() in module unload time, does that code > > run in user process context just like system calls do? That is > > important, because if it cannot sleep, it would deadlock. > > > > Not relevent. You have apparently made up your mind that you > need to do it "your" way. Fine.
No, no, that is not MY way. That is the 2.6 way. (see http://lwn.net/Articles/64444/).
With the old API (kernel_thread) there was no way (at least, direct way) to bind a thread to a cpu, which i actually need. And this is not MY own approach , it is used throught the kernel:
* migration thread at sched.c: http://lxr.linux.no/source/kernel/sched.c#L4196
* ksoftirqd thread at softirq.c: http://lxr.linux.no/source/kernel/softirq.c#L350
* worker thread used in workqueues: http://lxr.linux.no/source/kernel/workqueue.c#L182
...and so on
All these threads are standard and well debugged, and all use the API which I was talking about. Of course, as they are included in the official kernel sources, none of them is stopped at module unload time.
Thus, all I want to know is why kthread_stop() cant be called at module unload time, if the cleanup code can sleep and if there is a workaround for that.
I hope my questions are clearer now. Thanks for your help
Aritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |