lkml.org 
[lkml]   [2003]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.872 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site