Announcement

Collapse
No announcement yet.

Have the drm.git kernel modules been abandoned?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Have the drm.git kernel modules been abandoned?

    As title says, will users be forced to use in-kernel DRM drivers? I saw a message in Gentoo's repo that those kernel modules will be removed from it due to upstream not supporting them anymore.

    If yes, that's pretty sad; driver updates will be tied to kernel upgrades ("upgrade everything or nothing, sucker.")

  • #2
    Practically speaking, yes. As the rate of kernel change increased the effort required to keep out-of-kernel trees working with a variety of kernel versions increased as well, to the point where it became impractical with the available manpower. Support for new hardware is still sometimes backported to older kernel trees, but in general people seem to be picking up new kernels more aggressively for other reasons, typically to enable support for some *other* new hardware.

    On the other hand, most of the driver functionality is still in the user mode driver components. You need to pick up new kernel versions frequently while the graphics stack is going through these big changes, but once things settle down I think you'll find things aren't much different from before.
    Last edited by bridgman; 09-19-2009, 01:10 AM.

    Comment


    • #3
      Dunno how big a part it played with all of this but having a separate DRM tree that has to be kept compatible with all future and past kernel versions very fast ends up as a Bloody Mess. Also sooner or later you start having failures at forward-ports to new kernels only being partially complete so users who are using DRM modules from repo experience completely unexpected and unexperienced bugs by devs who are using stuff that's ending in and exists in kernel. The code gets much clearer and better maintainable and expandable if it stays without compatibility hacks. The old approach gave an illusion of a static API/ABI (which never existed except throughout compatibility hacks), now things show all the way to end-users more like how they really are.

      Comment


      • #4
        It's nothing tragic, just a deep personal hatred about the way drivers work in Linux :P They come as a "big, fat bunch", all inside the kernel. Reminds me of those "super duper 846-codecs pack" on Windows; I hated those too. Drivers should be separate entities. But I guess since Linux totally lacks a driver interface, we have to live with it.

        Comment


        • #5
          Originally posted by RealNC View Post
          It's nothing tragic, just a deep personal hatred about the way drivers work in Linux :P They come as a "big, fat bunch", all inside the kernel. Reminds me of those "super duper 846-codecs pack" on Windows; I hated those too. Drivers should be separate entities. But I guess since Linux totally lacks a driver interface, we have to live with it.
          You don't know about loadable driver modules? Drivers do NOT need to necessarily be "built in" to the kernel. They can be built outside the kernel and loaded in on an as-needed basis, the same as that *other* (junk) OS. Sure they have to be built against relevant kernel source, but same thing goes again with that *other* OS -- when was the last time that you saw a driver that truly worked for more than one version of microshod? Now where the loaded kernel modules really shine is in enterprise linux, i.e. RHEL, which maintains a single kernel version across all updates to a major version and thus modules remain compatible. RHEL6 will have a new kernel version from RHEL5 and therefore will require all new drivers.

          Now one of the big reasons for keeping the driver source with the kernel is this; it means that when you install the latest kernel, you get all the drivers for everything. WHY would you want to have to go on a driver hunt? Aren't we beyond that? Leave that driver hunting nonsense to microsheep.

          Comment


          • #6
            Originally posted by lbcoder View Post
            You don't know about loadable driver modules? Drivers do NOT need to necessarily be "built in" to the kernel.
            How can I *not* know about them. You totally missed my point.

            Now one of the big reasons for keeping the driver source with the kernel is this; it means that when you install the latest kernel, you get all the drivers for everything. WHY would you want to have to go on a driver hunt? Aren't we beyond that? Leave that driver hunting nonsense to microsheep.
            You really don't get it. I don't want driver hunting. I want drivers without having to either wait for the next kernel release (why the hell should I wait for the *whole kernel* to be updated if I only want a single driver?) or needing to update to the next kernel release.

            Instead of driver hunting, in Linux we have kernel hell. Something in the new kernel doesn't work for you? Some nasty regression? Too bad, sucker. You need to downgrade to an older kernel and by doing so downgrading *every* freaking driver too. It's all or nothing. That is what I call brain damage.
            Last edited by RealNC; 09-20-2009, 09:57 AM.

            Comment


            • #7
              Originally posted by RealNC View Post
              Instead of driver hunting, in Linux we have kernel hell. Something in the new kernel doesn't work for you? Some nasty regression? Too bad, sucker. You need to downgrade to an older kernel and by doing so downgrading *every* freaking driver too. It's all or nothing. That is what I call brain damage.
              One option is to use a distro which has capable and patient developers who backport features to older kernels but still avoid breaking anything. (a lot of the time requires they actually understand how the drivers work themselves)

              Comment


              • #8
                I guess that distros will start taking code from the kernel and drm-next and backport into their distro kernels, as Fedora already does. So for ordinary users not much will change.

                Users with mach64 chipsets will be sol though, as their drm is only in drm.git

                Comment


                • #9
                  Originally posted by chithanh View Post
                  I guess that distros will start taking code from the kernel and drm-next and backport into their distro kernels, as Fedora already does. So for ordinary users not much will change.

                  Users with mach64 chipsets will be sol though, as their drm is only in drm.git
                  Hmm, that's the DRM with security issues? Does anyone use Mach64 anymore anyway?

                  Comment


                  • #10
                    Originally posted by RealNC View Post
                    You really don't get it. I don't want driver hunting. I want drivers without having to either wait for the next kernel release (why the hell should I wait for the *whole kernel* to be updated if I only want a single driver?) or needing to update to the next kernel release.
                    I'm sure the Haiku project would welcome your contribution http://www.haiku-os.org/

                    Comment


                    • #11
                      I think we'll see distro schedules and kernel schedules gradually align themselves so that non-enterprise distros will automatically pick up the most recent kernel release while it's still fresh. Right now kernel packagers need to plan around both X and kernel release schedules in order to pick up new hardware, but as hardware-specific code moves out of the X drivers and into either the kernel or Gallium3D this should become a lot easier for everyone to manage.

                      I'm not sure if the Gallium3D code is built as a separate library or is linked into the state tracker, but there's a good argument for having it independent of the state trackers so that only the Gallium3D library needs to be updated. This is all "next year" stuff of course; there aren't enough drivers using Gallium3D yet for this to be a practical solution for distros today.
                      Last edited by bridgman; 09-20-2009, 01:42 PM.

                      Comment


                      • #12
                        The drm git would be also usefull when it would only work with the current kernel, because it is not really a good idea to compile the whole kernel over and over again after a small change when only drm would be needed.

                        Comment


                        • #13
                          Originally posted by Kano View Post
                          The drm git would be also usefull when it would only work with the current kernel, because it is not really a good idea to compile the whole kernel over and over again after a small change when only drm would be needed.
                          Code:
                          make modules SUBDIRS=drivers/gpu/
                          sudo make modules_install SUBDIRS=drivers/gpu/

                          Comment


                          • #14
                            Well ok, but why do i need to checkout the whole kernel tree when i only need drm?

                            Comment


                            • #15
                              Originally posted by Kano View Post
                              Well ok, but why do i need to checkout the whole kernel tree when i only need drm?
                              Because that's the way Linux works? It's not like you could build DRM anyway without something to build it against.

                              Comment

                              Working...
                              X