Re: [PATCH] f_op->poll() without lock_kernel()

From: Alexander Viro (viro@math.psu.edu)
Date: Sat Apr 22 2000 - 22:32:22 EDT

  • Next message: moussakx@jmu.edu: "Scheduler"

    On Fri, 21 Apr 2000, David S. Miller wrote:

    > Date: Fri, 21 Apr 2000 23:48:52 -0400 (EDT)
    > From: Alexander Viro <viro@math.psu.edu>
    >
    > > I think we don't want to keep it.
    >
    > There you go, then. ->fcntl() removed, call replaced with
    > sock_no_fcntl(), proto_ops and proto switched to new syntax. See if
    > it looks sane for you.
    >
    > This looks perfectly fine.

    BTW, if somebody wants the same sans ->fcntl() removal - tell and I'll
    send it (I _really_ have other things to worry about and I'm less than
    enthusiastic about picking fights over that interface - I think that
    ->fcntl() is strange method to have, but...)

    What I really don't like about the thing is the ->poll() interface. Here I
    _have_ some interest - it's used in NCPFS RPC. The main problem being: I
    would rather live without struct file for link to server. However, with
    sock->ops->poll() we have to keep one. Notice that
            a) all existing instances (in the main tree) start with
    unconditional poll_wait(file, <queue>, wait).
            b) after that point they do not care (and shouldn't care) for file
    and wait.
            c) in all cases except the net/atm/* stuff <queue> is
    sock->sk->sleep. In case of ATM we could set sock->sk->sleep so that it
    would point into the right place - no problems with that.
            d) if we declare that all poll-related events come at
    sock->sk->sleep (AFAICS reasonable) we could go for unsigned poll(sock)
    and leave poll_wait() to caller (normally sock_poll()).
            e) in many cases we are interested in ->poll() functionality, but
    couldn't care less for file. If we were guaranteed that ->sk->sleep points
    to the right wait queue we could get rid of quite a piece of mess in NCPFS
    RPC and potentially in other places.

            Comments?

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Sat Apr 22 2000 - 22:36:13 EDT