Hi Dave, > explains how you can do I/O from within kernel space.
At a glance I looked specifically for DIRECT IO in the article, I think it just explains cached IO from kernel buffer, which is very trivial and easy to do. Also I am reiterating here again, I have implemented one solution using do_mmap from inside the kernel and that works fine for DIRECT IO too. Please refer to my original mail But I am looking for a solution where I dont have to inject any kernel data into user space virtual address space. > Of particular note are the calls to set_fs/get_fs. These calls modify > the address space in such a way that copy_to/from_user will now work > on kernel buffers. You are right about set_gs/get_fs, I have done it sevaral times for doing cached IO. Problem area is get_user_pages function which tries to pin pages in memory and fails for kernel buffers. Thanks, Rajat On Tue, Oct 19, 2010 at 2:01 AM, Dave Hylands <[email protected]> wrote: > Hi Rajat, > > On Mon, Oct 18, 2010 at 1:14 PM, Rajat Sharma <[email protected]> wrote: > > Greg, > > > > okay I give you an example, currently ecryptfs does not support DIRECT IO > > operation, if it wants to encrypt data in kernel buffers and since file > was > > opened in DIRECT IO mode, the lower filesystem should not complain about > > kernel buffers > > Not sure if it's relevant, but this article: > <http://www.linuxjournal.com/article/8110> > > explains how you can do I/O from within kernel space. > > Of particular note are the calls to set_fs/get_fs. These calls modify > the address space in such a way that copy_to/from_user will now work > on kernel buffers. > > I'm pretty sure that this is NOT a recoemmended practice, but I > figured I'd throw it out there. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ >
