Re: new kmod.c - debuggers and testers needed
Perry Harrington (pedward@sun4.apsoft.com)
Tue, 7 Apr 1998 17:01:58 -0700 (PDT)
>
> Hi everyone,
>
> Okay, I just put a new version of kmod.c, along with my other versions of
> kmod on the web. They can be found at
> http://www.contrib.andrew.cmu.edu/~gaz/kmod/
>
> the newest one is kmod.c.v4
> I rewrote some of the code, greatly simplifying it.
> Instead of playing around with forking off two children, synchronizing
> them, and all of that pain, I thought it might be easier to have kmod
> instead respond to the SIGCHLD's when the fork()ed processes finish
> working. This makes the code a bit smaller and more readable. The only
> problem is that I can't program signal stuff in the kernel very well.
> After looking at the kernel source, I hacked up something that works, but
> not the way that it's supposed to. If anyone who knows more about the
> signalling members of the task structure, I'd be grateful.
> Basically I need the system to work as follows:
>
> request_module() gets called
> it initializes a new module slot
> it issues a signal (whatever: SIGCHLD or SIGUSR1) to kmod
>
> kmod receives the signal, and handles it by checking all module slots for
> things that need to be done
>
> a SIGCHLD from a finished modprobe would also wake up kmod, and have much
> the same effect.
>
Grr, interprocess synchronization where a kernel thread would be better. Why
not simply clone() a couple of worker threads to do all of this? It would
greatly simplify things WRT synchronizing and tracking events. Am I just
sounding like a kernel thread fanatic here, or does anyone else agree? Threads
are useful in their appropriate context, and kswapd, and kmod would benefit
from them.
>
...
>
> Greg Zornetzer - gaz+@andrew.cmu.edu
> "Light shines brightest in the darkest night"
> http://www.contrib.andrew.cmu.edu/~gaz
>
>
--Perry
--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu