Re: pre-2.1.90.. (kmod fix)
Itai Nahshon (nahshon@actcom.co.il)
Fri, 13 Mar 1998 00:16:04 +0200
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