Gilad, First, thanks for the answer.
On Thu, 2005-07-28 at 16:44 +0300, Gilad Ben-Yossef wrote: > A kernel thread is indeed proccess context, but since you brought it up > already and assuming we're talking 2.6, the "correct" way to do is use > work queues (and hence schedule_work) instead of schedule_task. This > will give you the option to start your own work queue (and hence your > own kernel thread) thus not having to worry about starving other tasks. > > And while we're on the subject, you might want to take a look into using > a work queue instead of a kernel thread all together - it's a very nice > interface to do these sort of things. > > To learn more about Work queues see here (page 23): > > http://lwn.net/images/pdf/LDD3/ch07.pdf Funny... I forgot all about work queues. Thanks! It'll save me the need to create way-too-many-kernel-threads. > > > On another different and related note, if you're consider doing IO from > kernel sapce (which is a terribly bad as you've pointed out already but > I wonder if you know just *how* difficult to debug and racy it is) The rest of the kernel code is already there. Let me put this way. The reset button is my new best friend :-/ I assume that I must guard all the file->ops->read/write file operation myself to prevent ugly race conditions, right? > for > fear of perfomance, a saner approach that may or may not fit your bill > is using RelayFS: > > http://sourcefrog.net/weblog/software/linux-kernel/relayfs.html Interesting... I remember reading about this in KernelTrap. I doubt that i'll help me. I need concurrent R/W from within the kernel space. > > > Hope this helps, > Gilad ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
