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

From: Keith Whitwell (keith_at_tungstengraphics.com)
Date: 09/29/04

  • Next message: Luke Kenneth Casson Leighton: "Re: [PATCH] to allow sys_pread64 and sys_pwrite64 to be used from modules" 
    Date:	Wed, 29 Sep 2004 15:39:37 +0100
To: Discuss issues related to the xorg tree <xorg@freedesktop.org>

    Keith Whitwell wrote:
    > Christoph Hellwig wrote:
    >
    >> 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.
    >
    >
    > I'd agree, but it's a widely distributed bug. I guess we can fix it in
    > the X server, but even better would be to rip out the code as it's
    > fundamentally misguided, based on a wierd idea that the kernel would
    > somehow ask the X server to perform a context switch between two
    > userspace clients...

    The piece of the puzzle you're missing is that the read() function really did
    used to do something, and was relied upon.

    If you want to go right back to prehistory, the drm was originally designed as
    a "core + personality" system, where the core supported a number of different
    context switching mechanisms to cover a variety of hardware cases. The gamma
    driver exercised one path, but everything since then has been a lot more
    simplistic, assuming that the hardware state is lost if another context has
    been active.

    Hardware often has the capacity to hold multiple active contexts or to perform
    fast hardware context save & restore. None of the DRI drivers have attempted
    to take advantage of that - optimization continues to focus on the
    single-client scenario.

    A future X-on-GL world where regular applications are presumably doing direct
    rendering will change that assumption...

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

  • Next message: Luke Kenneth Casson Leighton: "Re: [PATCH] to allow sys_pread64 and sys_pwrite64 to be used from modules"

    Relevant Pages

    • Re: dapper freeze
      ... > hardware wrong, so that xorg is trying to load a driver that doesn't ... > warnings or if the drivers being loaded don't match your hardware. ... collect some more information and file a bug report. ...
      (Ubuntu)
    • Re: in wchich context dispatch routines work?
      ... > context of thread that issued io operation ... IoStartPacket is usually called by the dispatch routine. ... IoCompleteRequest call (for drivers which are above the hardware ones). ...
      (microsoft.public.development.device.drivers)
    • Re: Broken driver via-rhine.c in kernel 2.6.8-rc1
      ... I can't reproduce the bug on any of my hardware right now (it was there ... makes the difference between those drivers. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: in wchich context dispatch routines work?
      ... that it will be called in the context of the calling thread. ... top-level drivers) to send requests in system threads, ... > IoStartPacket is usually called by the dispatch routine. ... > IoCompleteRequest call (for drivers which are above the hardware ones). ...
      (microsoft.public.development.device.drivers)
    • MEDIA: Why It Makes Sense for Sun to Open-Source Java Libraries & Solaris Kernel
      ... | you consider Sun's move towards commodity based hardware, ... Sun is going to need drivers ... | available to Solaris is pitiful. ... That's the author's bug. ...
      (comp.unix.solaris)