Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [RFC][PATCH] Kernel thread signal handling. | From | David Woodhouse <> | Date | Mon, 13 Oct 2003 12:21:19 +0100 |
| |
On Mon, 2003-10-13 at 04:02 -0700, Andrew Morton wrote: > Sigh. Using signals to communicate with kernel threads is evil. It keeps > on breaking and each site does it differently and we've had plenty of bugs > due to this practice.
The point in cleaning up allow_signal() et al. is that it gets simple and it stops breaking. Not that I recall having signal problems with the JFFS2 garbage collection thread other than this one, mind you.
> Is there no way in which jffs2 can be weaned off this obnoxious habit?
We have a kernel thread which performs garbage collection on our log-structured file system, to make space ahead of time for writes to happen. It's purely an optimisation -- we also perform garbage collection just-in-time in the context of a process which wants to actually _write_, if there's no free space but some could be made.
This garbage collection involves reading, writing and erasing the flash. It takes CPU time and power. Sometimes userspace wants it to stop happening in the background; sometimes userspace wants it to resume again.
So userspace sends SIGSTOP, SIGCONT and SIGKILL to the garbage collection thread and all of them have the expected effect.
Since we handle these signals anyway, the normal wakeup of the GC thread when the amount of free space changes is also done by SIGHUP, which userspace can also send to trigger a single pass.
I don't any the benefit in changing this practice.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |