Re: New DRM driver model - gets rid of DRM() macros!

[Christoph H. <hc...@in...>]

On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote:
> Thinking about it, it may not have been a problem of crashing, but rather that 
>   the behaviour visible from a program attempting to read (or poll) was 
> different with noop versions of these functions to NULL versions, and that was 
> causing problems.  This is 18 months ago, so yes, I'm being vague.
> 
> The X server does look at this file descriptor, which is where the problem 
> would have arisen, but only the gamma & maybe ffb drivers do anything with it.

Indeed, for read you're returning 0 now instead of the -EINVAL from common
code when no ->read is present.  I'd say the current drm behaviour is a bug,
but if X drivers rely on it.

Similar in poll your return 0 now while the generic code return
(POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM) for fds without ->poll, and
again I'd say current drm behaviour could be considered a bug.

for ->flush there's no behaviour change of not supplying it.