Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping.
I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call. I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach. If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ? -----Original Message----- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Nicolai Haehnle Sent: Friday, March 19, 2010 1:26 PM To: Luc Verhaegen Cc: dri-devel@lists.sourceforge.net; mesa3d-...@lists.sourceforge.net; x...@lists.freedesktop.org Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers. On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <l...@skynet.be> wrote: > So, identify the volatile interfaces, and the more stable interfaces, > and then isolate the volatile ones, and then you come to only one > conclusion. Except that the Mesa core <-> classic driver interface also wants to change from time to time in non-trivial ways, and trying to force a separation there on people who don't want an additional set of compatibility issues to deal with is not exactly a friendly move. It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas. In particular, the Mesa core <-> classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel installations trivial. The (only?) issues with that in X.org are that: 1) there is a cultural aversion due to the bad experience with the horrible pre-modularization setup, and 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. cu, Nicolai _______________________________________________ x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
