Messages in this thread | | | Date | Tue, 14 Apr 1998 13:19:27 -0400 (EDT) | From | Greg Zornetzer <> | Subject | Re: 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
| |