Messages in this thread | | | Date | Mon, 13 Oct 2003 04:40:42 -0700 | From | Andrew Morton <> | Subject | Re: [RFC][PATCH] Kernel thread signal handling. |
| |
David Woodhouse <dwmw2@infradead.org> wrote: > > 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.
It will encourage kernel developers to use signals-to-kernel threads more, and we don't *need* this capability.
People think "I need to send a message to a kernel thread" and then, immediately, "ah-hah! I'll use a signal!"
> ... > 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.
Sounds like the GC should have been performed by a userspace process in the first place?
How does userspace identify the JFFS2 process to which to send the signal?
> I don't any the benefit in changing this practice.
Well I know I'm going to lose this one, but at least I get to bitch about stuff.
sysfs would be appropriate, as would a sysctl handler. An ioctl might even work, although it gets a visit from the ioctl police and sometimes it is hard to obtain an fd on the appropriate filesystem. If the call rate is low, `mount -o remount,...' can be used to send a message to a filesystem.
- 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/
| |