Messages in this thread | | | Subject | kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*) | From | Christophe Saout <> | Date | Sun, 15 Feb 2004 21:24:28 +0100 |
| |
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-udm1/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.
Usually, the dm-daemon client adds some work to a list under a spinlock and calls dm_daemon_wake. The next time the thread runs it calls the client work function which usually just grabs the whole list and processes it. The client work function can also indicate it wants periodic wakeup using a return value which is currently used in the multipath target but it's not sure whether this will be moved to a userspace daemon.
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.
Making dm-daemon use the kthread primitives would make dm-daemon a very small and stupid wrapper. Changing all dm targets to handle worker thread notification themselves would result in unnecessary code duplication.
It seems to me that this functionality could perhaps be somehow added to kthread without changing it too much... ?
I would like to double-check with Joe rushing forward on my own.
- 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/
| |