[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.053 / U:2.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site