[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHSET] FUSE: extend FUSE to support more operations
    On Thu, 13 Nov 2008, Tejun Heo wrote:
    > Hello, Miklos.
    > Miklos Szeredi wrote:
    > > 0006-FUSE-implement-unsolicited-notification.patch
    > > 0007-FUSE-implement-poll-support.patch
    > >
    > > This would be nice, but... I don't really like the fact that it uses
    > > the file handle. Could we have a separate "poll handle" that is
    > > returned in the POLL reply?
    > Eh... I replied too early for this. I'm now trying to convert it to its
    > own handle but there is a rather serious problem. It's usually much
    > easier to have the entity to be waken up registered before calling
    > ->poll so that ->poll can use the same notification path from ->poll ans
    > for later.
    > However, if we allocate poll handle from ->poll and tell it to kernel
    > via reply, it creates two problem. 1. the entity which is to be waken
    > up can't be registered prior to calling ->poll as there's nothing to
    > identify it, 2. the interval from reply write and in-kernel polled
    > entity registration must be made atomic so that no notification can come
    > through inbetween. #1 means that ->poll can't call the same
    > notification path from ->poll itself and #2 means that there needs to be
    > special provision from dev.c::fuse_dev_write() to
    > file.c::fuse_file_poll() so that atomicity can be guaranteed. Both of
    > which can be done but I'm not really sure whether using a separate
    > handle would be a good idea even with the involved cost.

    Yeah, I see the problems.

    > Why do you think using separate poll handle would be better? And do you
    > still think the overhead is justifiable?

    Because it would be a change in the semantics of the file handle.
    Previously it was just an opaque cookie that the kernel stored for the
    filesystem, not making any assumptions about it (like uniqueness).

    OK, we can say that if the filesystems wants to implement poll, it has
    to make the file handle unique. Also now the filesystem (or
    something) has to deal with races between poll notification and
    reuse of the file handle (release/open).

    With a new poll handle we'd have more room to properly deal with these
    without overloading the file handle with extra requirements.

    How about this: the poll handle is allocated by the kernel, not by the
    filesystem. This guarantees uniqueness, so the filesystem cannot get
    this wrong. Releasing the poll handle is still tricky, there could be
    various races... only the userspace filesystem knows if it has no
    outstanding notificiatons on a poll handle, so the release has to come
    after all outstanding notifications have been ack'ed. Something like

    (userspace <- kernel)

    <- POLL-request(pollhandle) (alloc handle)
    -> POLL-reply
    -> POLL-notification(pollhandle)
    <- POLL-ack
    <- POLL_RELEASE(pollhandle)
    -> POLL_RELEASE-reply (free handle)


     \ /
      Last update: 2008-11-13 12:51    [W:0.021 / U:44.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site