On Wed, Feb 09, 2005 at 10:05:38AM +0000, Alan Hourihane wrote: >On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: >> On Tue, Feb 08, 2005 at 11:52:27PM +0000, Alan Hourihane wrote: >> >On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: >> >> On Tue, Feb 08, 2005 at 11:24:43PM +0000, Alan Hourihane wrote: >> >> >On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: >> >> >> On Tue, Feb 08, 2005 at 05:12:29PM +0000, Alan Hourihane wrote: >> >> >> >On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: >> >> >> >> On Tue, Feb 08, 2005 at 04:40:42PM +0000, Alan Hourihane wrote: >> >> >> >> >On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: >> >> >> >> >> It looks like the DRM kernel source in xc/extras/drm is broken >> >> >> >> >> and >> >> >> >> >> incomplete, especially for BSD platforms. The Linux version only >> >> >> >> >> appears to build for a narrow range of kernels, and this either >> >> >> >> >> needs to be fixed, or the minimum kernel requirements enforced in >> >> >> >> >> the Makefile. >> >> >> >> >> >> >> >> >> >> Perhaps we'll have to roll back to an older version that does >> >> >> >> >> build? >> >> >> >> > >> >> >> >> >I suspect pulling in a newer snapshot would be better, although >> >> >> >> >it's >> >> >> >> >a little more complicated now because the drm has split out support >> >> >> >> >for linux 2.4 and 2.6 kernels is separate subdirectories. >> >> >> >> >> >> >> >> Does the build automatically figure out which to use based on the >> >> >> >> kernel version, and what range of kernels has it been verified on? >> >> >> > >> >> >> >No. >> >> >> >> >> >> Any imports/updates need to address our requirements in this regard. >> >> > >> >> >If we import the current DRM trunk code, there are three linux >> >> >directories. >> >> > >> >> >1. linux for 2.4 kernels (monolithic) >> >> >2. linux-2.6 for 2.6 kernels (monolithic) >> >> >3. linux-core for 2.6 kernels with modular drm.ko and >> >> ><driver>.ko >> >> > >> >> >and two for bsd >> >> > >> >> >1. bsd monolithic >> >> >2. bsd-core modular as above >> >> > >> >> >The -core are the new ones going forward and which I believe has been >> >> >merged in linux 2.6.11. >> >> > >> >> >So, for now the linux-2.6, linux and bsd directories are the ones to >> >> >stick >> >> >with for stability. But things are changing. >> >> > >> >> >There'll be necessary build tweaks to select which directories are >> >> >needed. >> >> >> >> At this point in our release cycle, the priorities are: >> >> >> >> 1st: It builds/runs and is reasonably stable on a good range of >> >> platforms. >> >> 2nd: It supports as many DRI features as possible consistent with the >> >> first priority. >> >> >> >> I don't think that even changing from the existing single Linux directory >> >> to two different kernel-specific directories is appropriate at this point >> >> in our release cycle. The time for such a change was before the feature >> >> freeze. >> >> >> >> If what we have now is too broken to be fixed without major structural >> >> changes, then it will need to be rolled back. >> > >> >The fear is, if you roll back the DRM, then the drivers may need to be >> >rolled back as well to support lesser features. >> >> Some have said here today that the drivers can adapt to older DRM >> versions. That's how it should be, but I don't know if it is true >> or not. I've seen some things in my initial testing that may cast >> some doubt on it, but there were too many other variables to be >> certain without followup. >> >> It would clearly be preferable to have a recent version that works. >> Is there a known recent stable/working version? From my point of >> view the fear is, updating to the latest version, adapting to its >> structural changes, and finding that the result is no better. > >But isn't it better to move forward than backwards ? > >If the result is no better, then we need to fix the problems found. Going >back to an older version, and just because it builds, doesn't guarantee it's >going to work any better either. > >I've got more faith in the current DRM CVS as people are actively working >on it, rather than using an older snapshot that people could be unwilling >to go back and fix if a problem was found.
I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. David _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
