Re: New proposed DRM interface design

From: Felix Kühling (fxkuehl_at_gmx.de)
Date: 09/05/04

  • Next message: Rafael J. Wysocki: "latency.c [was: Re: 2.6.9-rc1-mm1]" 
    Date:	Sun, 5 Sep 2004 01:08:00 +0200
To: Dave Airlie <airlied@linux.ie>

    I realized, that from a snapshot point of view, it would be easy to cope
    with a separate library module + additional binary interface. As far as
    I gathered the main argument against another binary interface is that
    upgrading one driver would break the other ones that may still be
    installed on the system. It would be no problem to update all of them at
    the same time. The snapshots include all the DRM sources anyway, they
    just build the DRM for a single type of card right now.

    The snapshots have been split into a common and a hardware-specific part
    some time ago. Just move the DRM into the common part of the snapshots
    and make it build and upgrade all DRM drivers at the same time. This way
    a change in the binary interface won't break any other drivers (provided
    that DRM CVS is the authoritative source for *all* DRM drivers that rely
    on that library module).

    Regards,
      Felix

    On Sat, 4 Sep 2004 23:17:40 +0100 (IST)
    Dave Airlie <airlied@linux.ie> wrote:

    >
    > Actually after sleeping on this, I've just realised technically whether
    > the code is in a core separate module or driver module is only going to
    > affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
    > following the principles of a)least surprise, b) kernel must remain
    > stable, I think I can proceed with moving stuff into libraries and the
    > likes without making the final decision until later, we will probably
    > start with having the library type code in the driver (where it is now)
    > and make it possible to change later, as it evolves..
    >
    > I'll do some more research...
    >
    > Dave.
    >

    | Felix Kühling <fxkuehl@gmx.de> http://fxk.de.vu |
    | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
    -
    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: Rafael J. Wysocki: "latency.c [was: Re: 2.6.9-rc1-mm1]"

    Relevant Pages

    • RE: KB913648 Volume Shadow Copy Service update
      ... When responding to posts, please "Reply to Group" via your newsreader so ... You've already posted this idea about resizing the shadow storage due to ... VOLSNAP.SYS driver used to take and manage volume snapshots requires ...
      (microsoft.public.windows.file_system)
    • RE: KB913648 Volume Shadow Copy Service update
      ... VOLSNAP.SYS driver used to take and manage volume snapshots requires paged ... 65536 bytes of paged pool are allocated. ... Reduce the amount of snapshot storage used for all volumes so that your ...
      (microsoft.public.windows.file_system)
    • Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1
      ... >>given that they are completely different from the controller we know ... > single driver to drive both controllers or two independent drivers is not ... Shared code in a third module, a "library module", is an acceptable ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    Loading