[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

On 02/11/2010 10:01 PM, Miklos Szeredi wrote:
>> That's the requirement coming from allowing the server to determine
>> how these mmaps are served, not from the fact that the management is
>> done via server side mmaps or the server maps those regions into its
>> process address space. No matter how you do it, if you want to mix
>> and match client mmap requests, the SHMLBA alignment will be visible.
> Can you give an example?

Hmmm... I don't have any specific example. osspd is the only real
thing which uses it and it serves each mmap request with a separate
region. Oh... the fmmap example program serves the same region to
mmap requests coming from the same UID, so it does both sharing and
putting maps apart.

>> I suppose you're talking about not allowing offsets to be adjusted at
>> all but I don't think that's a restriction we would want to have at
>> the kernel API level because offset might encode different things for
>> device mmaps.
> Possibly. But there's some confusion about offsets again. This
> offset is not the same as the one currently returned in fuse_mmap_out.

This offset is the offset client requests.

> And neither is the SHMLBA alignment requirement so clear:
> You say, that ossp ignores the client mmap offset. So basically it
> resets the offset to zero, whatever it was, no? That sounds fine, but
> then you are adjusting the offset by something not necessarily a
> multiple of SHMLBA.

Yeap and that would be a bug. It will probably have to do % SHMLBA on
the offset. I don't think all OSS drivers would be caring about these
stuff anyway. Most of them work on only x86 where SHMLBA == PAGE_SIZE.

> So there are different offsets:
> a) vma->vm_pgoff (which may mean anything, but usually means b)

Yeap, vma->vm_pgoff can be any value and doesn't really matter. The
only visible difference would be the /proc listing, right? Setting
this to the requested offset is trivial.

> b) the offset at which the pages of the mapping are located
> c) the offset at which the server side mmap is located

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.

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.



 \ /
  Last update: 2010-02-11 14:25    [W:0.079 / U:1.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site