Messages in this thread | | | Date | Sat, 25 Apr 1998 20:59:43 -0400 (EDT) | From | Greg Zornetzer <> | Subject | Re: Linux-2.1.98.. - kmod |
| |
On Thu, 23 Apr 1998, Linus Torvalds wrote:
> > I just released a fairly small patch to 97 to bring it up to 98.
[snipped list of updates]
> There's been a lot of discussion and patches on capabilities, and I > haven't applied them yet, I'll let them simmer a bit. Similarly, I've seen > so many pathes to kmod that my head is spinning, and as I don't use > modules myself I'd really like to get feedback from users about the > different patches, so that maybe I'll get something that everybody can > agree on as acceptable. Right now I don't know which patch I should even > begin looking at.
I'd highly suggest the "daemonless kmod" patch posted by Adam Richter in the last couple of days. If you do not have them, I'd be happy to send them to you. I just placed a copy of Adam's patch on the web at http://athena.res.cmu.edu/kmod/kmod.patch.2198
Forgive the slightly long-winded explanation below, but I'd like to put all of the facts w.r.t. kmod in one place
The current kmod is inadequate. The main reason for this is that kmod is currently only able to handle one module request at a time. Any module that calls request_module within its init code will fail to load properly. This makes modular scsi and modular parallel port/printer unworkable with the current autoload system. This could be worked around in the code for printing and scsi, but it will probably be quite difficult. Even if such a workaround was done, there could still be problems with overlapping module requests that are unrelated. Say we fork and exec lpr in the startup scripts, and then run a program that requests the sound modules. It is possible that these requests will overlap. The current kmod behavior tends to silently drop second and third module requests when a first one is pending.
Can the daemon kmod be "fixed" so that it will handle multiple module loading? Yes and no. I was working on such a fix, but I could see in the code that there were several concurrency bugs that could cause kmod to work improperly on an SMP system. The code seemed to work, but I knew that it could fail under SMP, or in "special" circumstances. The code was also getting quite bloated.
What the daemonless kmod does differently. Instead of running a seperate kmod daemon, the daemonless kmod runs a kernelthread from within request_module(). This kernelthread exec's modprobe to load the module. request_module() executes a waitpid() to allow it to be signalled when modprobe is complete.
The code to do this is quite small (I think it may be smaller than the original kmod), and is fairly straightforward. The code has a few security checks to make sure that a hacker can't run a bogus modprobe, or mess with open files, etc. It allows an arbitrary number of module requests to be running at the same time, and is (AFAIK) inherently SMP safe, since each request is handled by its own request_module and short-lived kernel-thread. The only thing that looks rather strange about the code is that the syscall is doing a kernel_thread() and waitpid() on behalf of the calling process.
Other thing: autounloading must (and should) be done in userspace with 'rmmod -a' in the crontab or a simple program that executes 'delete_module(NULL) every few minutes. This delivers functionality _indentical_ to the older kmod, and kerneld. In fact, if you run kerneld on a system running this kmod patch, kerneld takes care of module unloading without interfering with daemonless kmod loading.
Finally: user feedback. Since seeing this patch come out, I have seen it fail only once, and that was on an Alpha, reported by Steve Hirsch. Subsequent investigation showed that the problem lay in the setting of the sigmask, and has been fixed in the last two patches. I have heard of no failures with the latest patch on any architecture.
In short, it seems to work. Linus, I hope you find this feedback useful.
Greg Zornetzer - gaz+@andrew.cmu.edu "Light shines brightest in the darkest night" http://www.contrib.andrew.cmu.edu/~gaz
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |