lkml.org 
[lkml]   [1998]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.206 / U:26.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site