> 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 - email@example.com
"Light shines brightest in the darkest night"
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org