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

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


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 : Sun Apr 23 2000 - 21:00:21 EST