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

Christoph Hellwig
2004-09-29T14:22:55Z

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.