[lkml]   [2007]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] epoll use a single inode ...

    On Wed, 7 Mar 2007, Eric Dumazet wrote:
    > sockets already uses file->private_data.
    > But calls to read()/write() (not send()/recv()) still need to go through the
    > dentry, before entering socket land.

    Sure. The dentry and the inode need to *exist*, but they can be one single
    static dentry/inode per "file descriptor type".

    We always pass in the "struct file *" to read/write too, since we need it
    anyway for things like file control information (eg "is it a nonblocking
    read or write" kinds of things).

    So I'm not suggesting a NULL dentry/inode, I'm suggesting a single static
    one per type.

    And yeah, it may be harder than it looks. Some things "know" that all the
    relevant info is in the inode, so they just pass in the inode. In the pipe
    layer, for example, you'd need to change free_pipe_info() and
    alloc_pipe_info() to pass in the file descriptor instead, same goes for
    pipe_release(). But the "struct file *" is always available, it's just
    that since the code was originally written to have all the info in the
    inode, some of the code isn't set up to use it or pass it on..

    But your patch is independent of that, and looks fine. Except I don't like
    this part:

    - file->f_path.mnt = mntget(sock_mnt);
    + file->f_path.mnt = NULL;

    since I'd be much happer with always having f_path.mnt available, the same
    way we should always have f_path.dentry there.

    (Btw, your patch is *not* going to work with the file->f_private_data
    approach, because d_path() is not passed down the "file *" thing. So we'd
    need to do that, and that's more intrusive (it can be NULL, since for
    things like cwd/pwd we don't have a "struct file").

    But I like your patch as a totally independent thing. "It just makes

    (Apart from the f_path.mnt thing, which I think was something else ;)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-07 18:55    [W:0.021 / U:85.628 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site