Messages in this thread | | | Date | Tue, 7 Apr 1998 21:44:08 -0400 (EDT) | From | Greg Zornetzer <> | Subject | Re: new kmod.c - debuggers and testers needed |
| |
On Tue, 7 Apr 1998, Perry Harrington wrote: [snipped my explanation of kmod]
> > 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. I was originally doing something somewhat like this, but the problem is that I was using a wait_queue for waking up kmod, and also a semaphore to control access to the linked list of module information. I could have gotten rid of the wait_queue, but the kmod would be looping, taking up valuable CPU cycles unnecessarily. There were several (albeit unlikely to occur) races in the code, because I couldn't guarantee that the sleep_on and wake_up calls could be done atomically with the changing of the semaphore. I couldn't guarantee that a wakeup wouldn't occur just after kmod released the semaphore but before it went to sleep_on. At least this was my understanding. You are welcome to examine the code.
The use of signals simplifies the matter because a handler is automatically spawned regardless of the state of kmod. It just seems like a clean and race-free way of doing things.
In principle, Kmod is very simple, but taking care of all of the little details (multiple modules, request_module()'s at odd times) make the coding more difficult.
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
| |