lkml.org 
[lkml]   [1998]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: new kmod.c - debuggers and testers needed
Date
> 
> Hi everyone,
>
> Okay, I just put a new version of kmod.c, along with my other versions of
> kmod on the web. They can be found at
> http://www.contrib.andrew.cmu.edu/~gaz/kmod/
>
> the newest one is kmod.c.v4
> I rewrote some of the code, greatly simplifying it.
> Instead of playing around with forking off two children, synchronizing
> them, and all of that pain, I thought it might be easier to have kmod
> instead respond to the SIGCHLD's when the fork()ed processes finish
> working. This makes the code a bit smaller and more readable. The only
> problem is that I can't program signal stuff in the kernel very well.
> After looking at the kernel source, I hacked up something that works, but
> not the way that it's supposed to. If anyone who knows more about the
> signalling members of the task structure, I'd be grateful.
> Basically I need the system to work as follows:
>
> request_module() gets called
> it initializes a new module slot
> it issues a signal (whatever: SIGCHLD or SIGUSR1) to kmod
>
> kmod receives the signal, and handles it by checking all module slots for
> things that need to be done
>
> a SIGCHLD from a finished modprobe would also wake up kmod, and have much
> the same effect.
>

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.

>
...
>
> Greg Zornetzer - gaz+@andrew.cmu.edu
> "Light shines brightest in the darkest night"
> http://www.contrib.andrew.cmu.edu/~gaz
>
>

--Perry

--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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