Re: DRM kernel source broken/incomplete

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