[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B7400A7.5070105@kernel.org>
Date: Thu, 11 Feb 2010 22:05:43 +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/11/2010 09:46 PM, Miklos Szeredi wrote:
> The problem with that is you simply can't determine in advance where
> the region will grow. Okay, you can leave space according to the size
> of the file, but the size of the file can grow too.
>
> *This* is the complexity that I want to get rid of.
Alright, then let's talk about that, not SHMLBA which doesn't really
have much to do with this. So, you're basically saying that you want
multiple address spaces. In that case, the only logical abstraction
for that are files. ie. We need to be passing file descriptors to the
server and asking the server which descriptor it would want to use,
which was the previous implementation, which you objected mentioning
that this type of direct mmap would probably be useful only for device
mmap implementations.
The address space provided for dmmap is huge. It's any range which
pgoff_t can address. I really can't imagine managing allocation from
that space causing problems. If you want to use it for multiple huge
mappings, we can't use the simple implementation w/ pinned pages
anyway. We'll have to borrow anonymous file implementation or
implement private swap backing.
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