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

From: Andi Kleen (
Date: Tue Apr 25 2000 - 04:17:55 EST

On Tue, Apr 25, 2000 at 04:44:19AM +0200, Alexander Viro wrote:
> On Sun, 23 Apr 2000, Andi Kleen wrote:
> > On Sun, Apr 23, 2000 at 04:33:52AM +0200, Alexander Viro wrote:
> > > 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
> >
> > I don't see the gain behind the change. Please keep it as it is. I prefer
> > to think about TCP/UDP poll as a generic poll like all other poll functions,
> > not a specially-hacked networking poll. Flatter hierarchies are better here.
> My main beef with the ->poll() in net/* is that it forces us to carry
> struct file around, even though there's often no other reason to do that.
> It is _wrong_ - when you have to allocate dummy objects to make the
> interface happy it means that you are using the wrong interface. Hell
> knows... I'ld rather avoid mixing these things - selection of waitqueue to
> wait on is one thing, actual asking about the events is completely
> different. BTW, AFAICS the former can be done at the open()/socket()
> time...

Unless you change that everywhere it is better to keep the networking
poll the same. To many different ways to do the same thing cause
swapping in the programmer's brain, which causes bugs in the long run.

Also BTW there are possible future optimizations that require the files
struct, like a cleaned up version of the poll hints patch at


This is like TV. I don't like TV.

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

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST