Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support

[Tejun Heo <tj@kernel.org>]

Hello,

On 02/11/2010 06:31 PM, Miklos Szeredi wrote:
> On Thu, 11 Feb 2010, Tejun Heo wrote:
>>> If there's a pattern there, we might make the sharing/non-sharing
>>> automated, and greatly simplify the interface.
>>
>> Isn't the interface pretty simple as it is?
> 
> On one hand it's simple, on the other it has pretty weird
> limitations, considering that server side mmap shouldn't be
> mandatory.

It's not like it's something completely foreign.  It's a limitation
which can also be found in shared memory and the server side mmap
doesn't really have much to do with it.  It's also necessary to avoid
aliasing issues among clients.

> But of course if server side mmap isn't used, then the SHMLBA
> limitation is not necessary anymore so the implementation could
> choose an arbitrary "offset".

It of course is necessary.  How else can aliasing among clients be
avoided?  The alignment is not only for the server.  If you're gonna
share memories and want to adjust the mapping in any way, you need to
follow the SHMLBA alignment.

> My biggest gripe with the kernel API is that we shouldn't be calling
> that thing in fuse_mmap_out an offset at all, because it's not and
> it's confusing (like making you set vma->vm_pgoff to that value, which
> is bogus).  Adding a separate "page_id" or whatever would make me
> happy.

It _is_ an offset into the dmmap address space.  mmap() requests to
map certain length at certain offset of an address space.  The FUSE
server can redirect the offset to make it share, not share or combine
or whatever.  It's very simple conceptually.

> And if the server wants to mmap /dev/fuse then it can do that and send
> the result in "dev_offset", to make it clear that it's a different
> offset from the one the client used on the mmap.  And it can even use
> that value as page_id, if it wants to or it can use a different
> page_id.
> 
> Does that sound reasonable?

I can't really follow what you're suggesting.  Either you're
misunderstanding why SHMLBA is necessary or I'm being plain dumb.  Can
you please describe what you have on mind without referring to the
current implementation?  How would it work?

>> If we want to make it easier for API users by imposing limits, I
>> think the correct layer to do that would be at the library level.
> 
> Hmm, might do that.  High level library users definitely shouldn't be
> having to mess around with SHMLBA.

The main thing would be to let the library manage mmap regions and ask
the server only two things - region size and share ID both of which
are optional.  If both are not set (ie. -1 and -1), the mmap request
won't be shareable and sized as requested by the client.  If the
server returns a positive ID, all mmap requests with the same ID will
share the region.

Also, I said it before but SHMLBA is something which is already known
to the userland for shared memories.  I really don't think this is too
much to ask for if the server is playing with direct mmap.

Thanks.

-- 
tejun