[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B749FF8.6030304@kernel.org>
Date: Fri, 12 Feb 2010 09:25:28 +0900
From: Tejun Heo <tj@...nel.org>
To: Miklos Szeredi <miklos@...redi.hu>
CC: mszeredi@...e.cz, linux-kernel@...r.kernel.org,
fuse-devel@...ts.sourceforge.net, polynomial-c@...too.org,
akpm@...ux-foundation.org
Subject: Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support
Hello,
On 02/12/2010 09:07 AM, Tejun Heo wrote:
>> The thing is, I'm still not sure if or how this kind of mmap makes
>> sense outside of the CUSE context. Which makes designing the API
>> difficult.
>
> For this to be useful for normal FS, it has to be backed by multiple
> swap backed files and I can almost guarantee you would need to be
> passing fds around.
BTW, if you're looking this way, one way to do it would be to ask the
server to return a fd to use for the mmap backing and offset
adjustment (still needs to be SHMLBA aligned) rather than creating
anonymous file from the kernel. In this approach, the problem would
be wrapping the vma ops so that FUSE can determine when the mmap
segment is released. I did it in pretty ugly way in the previous mmap
implementation by simply overwriting the ops as anonymous files didn't
have their own ->open or ->close but to do this for any file you'll
need a way to nest or inherit vma ops in generic way. The problem is
that the assumptions regarding vma are pretty deeply buried all over
the VM layer. FWIW, I couldn't think of a way to do that in generic
manner.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists