Messages in this thread | | | From | Perry Harrington <> | Subject | Re: new kmod.c - debuggers and testers needed | Date | 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
| |