Messages in this thread | | | Date | Tue, 7 Apr 1998 19:36:23 -0400 (EDT) | From | Greg Zornetzer <> | Subject | new kmod.c - debuggers and testers needed |
| |
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.
Anyway, get the kmod.c file at the above address, and try it out. I'm welcome to suggestions and improvements.
List of problems solved by this kmod.c 1. Multiple module loading allows scsi and parport stuff to load properly 2. request_module will not process anything, and return -1 until the thread is started.
List of problems and help needed with this kmod.c 1. Making the signal stuff work the way that it should. 2. Nailing that random memory corruption bug. I looked at kswapd, and it does many of the things that kmod does in terms of accessing kernel structures, but kmod still seems to cause random memory SNAFUs. mm help would be appreciated 3. This patch won't help the Alpha people - I remember an email saying that someone is looking in to implementing fork() properly for the alpha
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
| |