Re: [RFC][PATCH] Kernel thread signal handling.

[Andrew Morton <akpm@osdl.org>]

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.