Rami, Thanks for the link. It's an interesting read. (Though my intended solution goes even lower; sys_XXX calls the flip_XXX and ->read/write methods.) I total agree with the writer; If you need FS access for configuration files, you shouldn't be using the FS in a kernel modules in the first place.
Gibloa On Fri, 2005-07-29 at 04:05 -0300, rami rosen wrote: > Hello, > There is an articel in LinuxJournal from this April issue by Greg KH which > explains > how to read and how to write a file from kernel module. > He reads the file using set_fs(KERNEL_DS) and write to the file using > fget(fd) > and vfs_write(). > > It is clearly not recommended to do such a thing , as he admitted in this > article. > Moreover, the article itself is titled "Driving Me Nuts - Things You Never > Should Do in the Kernel". > see: > http://www.linuxjournal.com/article/8110 > > Regards, > Rami Rosen > > > > > > >From: Gilboa Davara <[EMAIL PROTECTED]> > >To: IL List <linux-il@linux.org.il> > >Subject: Re: File I/O within kernel threads? > >Date: Thu, 28 Jul 2005 17:24:41 +0300 > > > >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] > > > > _________________________________________________________________ > Don't just search. Find. Check out the new MSN Search! > http://search.msn.com/ > > > ================================================================= > 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] ================================================================= 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]
