Re: kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Rusty Russell <rusty@rustcorp.com.au>]

In message <1076876668.21968.22.camel@leto.cs.pocnet.net> you write:
> Am So, den 15.02.2004 schrieb Christoph Hellwig um 20:46:
> 
> > > The only reason, I guess, is that it depends on this very small
> > > dm-daemon thing:
> > > http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-u
dm1/00016.patch
> >
> > Well, actually the above code should not enter the kernel tree at all.
> > Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
> > submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
> > he could just include dm-crypt then.
> 
> Sure I could.
> 
> But kthread is currently not a full replacement for dm-daemon. kthread
> provides thread creation and destruction functions. But dm-daemon
> additionaly does mainloop handling.

Yes, looks like dm-daemon is a workqueue.

> There seems to beg a small race conditition that can appear when using
> only wake_up for notifies so dm-daemon uses an additional atomic_t
> variable to make sure nothing gets missed. Just see the function
> ``daemon'' in dm-daemon.c.

This is why using a workqueue, rather than having everyone invent
their own methods, is a good idea.

> It seems to me that this functionality could perhaps be somehow added to
> kthread without changing it too much... ?

You could build it on top of kthread probably.  You could also change
workqueues to resize dynamically, rather than be one per cpu (but
that's some fairly tricky code).

Thanks for bringing this code to my attention...
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.