Re: kthreads->kproc and back to kthread.. next patch

Julian Elischer wrote:
> Here is the link to the next patch.
> 
> this introduces (back) the kthread_create (etc) calls but now they
> make threads..

> it may also be worth adding some help for people to make a new kproc,
> and populate it with a number of kthreads.

For example, why would we do that? :)

A practical example: GEOM modules often spawn separate execution 
contexts to handle non-trivial IO requests. These threads are usually 
created at most once per GEOM device and live until that device goes 
away. GEOM framework itself has several execution contexts (g_up, 
g_down, g_event) which call "methods" from GEOM classes. Should we spawn 
one "dummy" kproc per GEOM class and then kthreads in it for devices? If 
"raw" kthreads can be spawned, to which kproc will they belong (if any)? 
  Is the difference between kthread and kproc here purely aesthetic?

In other words: when should one create a kproc and when a kthread?