On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <l...@skynet.be> wrote: >> 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 > > "put all the drivers in one repository"? > > So, all of: > * drm > * firmware > * libdrm > * xorg > * mesa/dri > * mesa/gallium > * libxvmc > * libvdpau > (add more here) > of the same driver stack, in one repository?
Why not? Mind you, I'm not advocating for any change at all, but as long as you feel the need to move stuff around, why not try finding a goal that people actually find useful? Of course, my suggestion is probably crap, too. [snip] > The real question is: where is the most pain, and how can we reduce it. > And the most pain is between the driver specific parts. Nobody has ever had to feel the pain of a separation between Mesa core and drivers. And since a git log I've just done tells me that you have committed only twice to the Mesa repository within the last year or so, maybe you should listen to the opinion of people who *have* been active in the Mesa tree when it comes to that subject, and are working on drivers that are probably significantly more involved than whatever Unichrome does. >> 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. > > The kernel people can have theirs. What stops anyone from getting the > drm code of a released driver stack into the next kernel version? > > But when anyone decides they need a new driver stack which requires a > new drm module, it should be easy to replace the stock kernel module. And that has worked so well in the past. cu, Nicolai ------------------------------------------------------------------------------ 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 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev