Messages in this thread | | | Date | Fri, 13 Mar 1998 00:16:04 +0200 | From | Itai Nahshon <> | Subject | Re: pre-2.1.90.. (kmod fix) |
| |
Kirk Petersen wrote: > > > The best way would probably be to drop the wait() call in kmod's kernel > > thread. Instead, let the parent do the loading and the child can do the > > next request. No waiting is necessary, as the parent will eventually die > > (it'll be reaped by init), thus the child will be reassigned to be a child > > of init (which is what we want). > > I'm not sure that is possible. When request_module() is called, > it shouldn't return until modprobe has exit()ed. If it doesn't do the > wait(), it might return early and the module won't be ready. > What I'm trying now is to have the kmod daemon fork two > processes, one to do the modprobe and one to wait for it and notify > request_module() that it is done. The daemon just goes back to waiting > as soon as these processes have started. > Why not try to fork out of the call to request_module? That may not be as convenient as a call from the kmod thread because you have to set permissions and close file descriptors for the new process, but it will solve (I hope) all other problems. The kmod thread may be left just for releasing modules (or is if possible to get rid of it too?). Alternately, fork out of the kmod thread, but do some cheating and let the process that called request_module wait in waitpid().
As in the current implementation, synchronization with only one global wait_queue is probably not enough. While a process is waiting in request_module, another process calling request_module (could be from init_module of the started module) may prematurely wake up the first one.
Itai -- Itai Nahshon nahshon@actcom.co.il Also nahshon@vnet.ibm.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |