Re: DRM function pointer work..

From: Dave Airlie (airlied_at_linux.ie)
Date: 08/07/04

  • Next message: Martin Mares: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices" 
    Date:	Sat, 7 Aug 2004 01:11:21 +0100 (IST)
To: Jon Smirl <jonsmirl@yahoo.com>

    >
    > fbdev is in exactly this model and it isn't causing anyone problems.
    > The simple rule is that if you want to upgrade fbdev past the current
    > version you have to do it in entirety. You do that for fbdev but
    > pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
    > something only developers do.

    fbdev only has one distribution vector - the kernel, DRM has multiple
    distribution vectors, kernel, DRI snapshots, X releases, they all contain
    their own DRM modules, also people with older kernels should be able to
    use new drivers with little hassle, if we force people to upgrade their
    kernel we are restricting what we allow them to do now ...

    If we do go for a library split, we should use the kernel config system
    like I mentioned and fight any attempts to change it, to re-iterate, if
    you build drm into the kernel you have to build the graphics drivers in as
    well, (we can use a symbol to enforce it), if you build the drm as a
    module all drivers have to be modular, and the DRM makefile installs the
    core DRM, we could also create a drm_ver.h file that gets
    generateed at compile time automatically and then included into
    both drm core and module at build time, if this differs just refuse to
    load and stick a FAQ up telling the user they are messing something up ..

    > The key here is that distributions release new kernels at a rapid pace.
    > This is not X where we get a new release every five years. The standard
    > mechanism for upgrading device drivers in Linux is to add them to the
    > kernel and wait for a release. If DRM uses that mechanism for
    > distribution we won't have problems.
    >

    Like Keith I don't buy this argument too much either, I think we should be
    able to continue as much as possible with what people can do now ..
    especially snapshot type systems..

    Dave. 

    -- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
-
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: Martin Mares: "Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices"

    Relevant Pages

    • Re: your mail
      ... Graphics drivers in the kernel are broken. ... Since fbdev has taken the path to pretend that DRM ... Part of being a first class driver means that DRM has ...
      (Linux-Kernel)
    • Re: OpenGL-based framebuffer concepts
      ... You might want to leave the DRM hot potato alone for a while and just ... Fbdev is smaller and it is easier to get changes ... For this reason I can't just leave DRM ... the last Kernel Summit. ...
      (Linux-Kernel)
    • Re: [Linux-fbdev-devel] Resource management.
      ... >> By default DRM builds in everything. ... > I just want it to work, with a Linux kernel you rarely get to an every ... fbdev api is designed to be very simple for the most common cases. ... As for the VGA class driver. ...
      (Linux-Kernel)
    • Re: DRM function pointer work..
      ... > fbdev is in exactly this model and it isn't causing anyone problems. ... > The simple rule is that if you want to upgrade fbdev past the current ... > upgrade he graphics driver he should wait until we push it into the ... > kernel and it arrives via his distribution. ...
      (Linux-Kernel)
    • Re: [PATCH] DRM: add missing pci_enable_device()
      ... It appears that the kernel bk tree is lagging behind the DRM CVS ... that these calls are handled by the fbdev device. ...
      (Linux-Kernel)