On Wed, Jun 30, 2004 at 21:39:07 +0530, Dhiman, Gaurav wrote: > As far as I could understand from the going on discussion on kernel > threads is that, we would create a kernel thread if we want something to > be done even if our module goes to sleep or the control returns back > from module to user space. This sounds confused. A module is not like a process. Module is like a library. So there is no notion of "module sleeping" and "module returning control" per se. A module is a library and it's functions may be called by different means. One of them is running in a kernel thread. > Lets say, our user process calls a system call which further invokes a > specific module code in kernel space, that module starts the kernel > thread and then that kernel thread (a totally different entity and > context from our module) calls the demonize() to detach itself from the > user process which called the module. Once this has been done and our > module control returns back to user space, there will still be a > different context (kernel thread module created) in existence and can be > scheduled when a call to schedule() will be made. This sounds confused, though mostly correct. Usualy, syscalls are completely handled on behalf of the process that invoked them. That means the function handling a syscall runs in context of that process and may do anything allowed in a process context, most notably may sleep. The kernel threads are usualy created by the module_init() function of given module (which is called by a syscall from insmod though). This function ends, but the kernel thread runs on. > I hope we can unload the module once the module has created the kernel > thread, as that thread is no more associated to module. Kernel thread is not associated with a module that created it. It's a stand-alone process. However, it runs some code. And that code must, obviously, be in memory for the thread to run. Unloading a module removes it's code from memory. So a kernel thread created by a module can outlive the module that created it, but can't run it's code anymore. > This is all what I understood from going on conversation. > Following are few of my doubts: > > 1. Once the thread has been created by module or core kernel, and that > thread detach itself from the process (which created it thru some > module) or the core kernel. Who will make that thread die ...... or in > other words, who will kill that thread? First, a thread can't "detach itself from the core kernel", because core kernel is not a process and does not resemble process in any way. Core kernel has several threads for doing things that must be done in a process-like fashion (idle thread, ksoftirqd, kswapd, pdflush etc...). The kernel thread IS A process. Processes usualy end by returning from main() or by calling exit(). So does kernel thread. Actualy, while processes can die of signal, kernel threads can't, because signals are handled during return to userland -- and that will never happen for a kernel thread. The signals are delivered though, so you can check for them explicitely. Kernel thread can die when it causes an OOPS. > 2. Its almost related to first question. Is it compulsory to kill the > thread which has been created by module? Lets say my driver created 2 > kernel threads in init_module() function of my module, do I need to > kill those threads in cleanup_module() function. Incase I don't kill > while cleaning up the module, who will kill those kernel thread. As far > as I think those kernel threads will remain there till the time we > shutdown the system. As I said above, you can't "kill" them in the sense "send them a fatal signal". As I also said above, if the thread executes code from your module, it would crash if you didn't stop it. But it's not sufficient to just tell it to finish. You must wait for it to actualy finish, before you let the module unload complete. Since you (the module_done function) are running in context of rmmod, which is not parent of those threads (init is), you can't use wait. So you must use a synchronization primitive. And there is only one that will work -- a completion. The complete_and_exit() is only way to acknowledge module exit and exit it without running a single instruction from your module in between. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@ucw.cz>
Attachment:
signature.asc
Description: Digital signature
