lkml.org 
[lkml]   [2010]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support
From
Date
On Thu, 11 Feb 2010, Tejun Heo wrote:
> >> There are three offsets.
> >>
> >> a) the offset a client requested
> >>
> >> b) the offset into dmmap AS, a client mmap region is mapped to. This
> >> could be different from a) by multiple of SHMLBA / PAGE_SIZE.
> >
> > No, it could be different from a) by an arbitrary value.
>
> Then, sharing those pages would cause aliasing issues.

You said a few mails up:

"There are device mmap() implementations which simply ignore @offset
because offsetting doesn't make any sense at all"

Which means a) doesn't necessarily matter, so it's not something that
determines aliasing issues.

> >> c) the offset into dmmap AS, a server mmap region is mapped to, where
> >> collection of these mmaps define the dmmap AS.
> >>
> >> The offsets used in b) and c) are the same offsets.
> >
> > Why are they the same?
>
> I meant they point into the same space. If they're the same value,
> they point to the same page.

I'm beginning to undestand what you mean by "dmmap AS".

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.

So, for now maybe it's best to go with your implementation, fix issues
with the offsets and make it CUSE only for the moment.

The alternative is for me to start implementing a coherent distributed
filesystem, so I can see what the actual requirements for a direct
mmap would be. That would be fun, but it would

a) delay direct mmap for CUSE by an unknown amount of time
b) delay everything else that I have in the pipeline ;)

Thanks,
Miklos


\
 
 \ /
  Last update: 2010-02-11 15:43    [W:0.080 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site