lkml.org 
[lkml]   [1998]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Testers wanted: exorcised kmod.c: no more daemon!
On Mon, 13 Apr 1998, Kirk Petersen wrote:

[snipped]
> I like the idea of removing the auto unloading code, since it is
> something that can certainly be done in user space. An argument *could*
> be made that not all systems have cron. But I've been thinking, how

a simple script that runs rmmod -a, then sleeps for 60 seconds, then runs
it again would work also...

> necessary is automatic unloading? I can't think of any good example
> where *auto* unloading is necessary. Sure, modules need to be unloaded
> at times, but the only examples I can think of involve modules being
> unloaded explicitely and immediately. Making modules *not* auto-unload
> by default would solve many of the "my mixer settings aren't saved"
> problems, too. I'm curious to know peoples thoughts on this matter.

so during this whole kmod fix process, I was thinking about problems of
extending kmod so that it's a more flexible interface between the kernel &
userspace. When I was looking through the kerneld code and saw the cute
things like replacing a beep with running a sound player, executing screen
savers instead of a screen blank, etc, I was thinking that instead of
request_module invoking /sbin/modprobe directly, it invokes a wrapper that
will call modprobe for the general case, but can be used for other tasks
also (even request_route, although as people have pointed out,
request_route is buggy at best).

Lets take the example of the mixer settings not saved problem.
If we could make a system where the mixer settings are made available by
sysctl, we could have a program that gets called via request_module in
init_module and cleanup_module that restores and saves mixer settings from
one module invokation to the next. Most of the work is in userspace, the
kernel just tells userspace when to do its thing.

Is this feasable, or do people consider this kind of thing to be an ugly
hack?

> Anyways, I'm running your code at home and it works great, but I
> don't have any "tricky" modules. If people don't find any major bugs,
> I think it should go into the kernel.

I've been running this with 2.1.96pre1 on my machine. It works quite
well. I'd suggest that anyone who is trying my patches, to try Adam's to
make sure that they work in all cases. Then we can get this into the main
kernel and won't have to worry about the (now Frequently Asked) question
of "why doesn't kmod load parport_pc when I load lp?" :)

>
> --
> Kirk Petersen
> http://www.speakeasy.org/~kirk/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

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.125 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site