lkml.org 
[lkml]   [2001]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 4.1.0 DRM (was Re: Linux 2.4.6-ac3)
John Cavan wrote:

> Jeff Hartmann wrote:
>
>> Actually I have something like this pretty much working. Unfortunately
>> I was working on a project full time during the 4.1.0 release. With the
>> addition of this code, the old modules will coexist with newer modules.
>> Basically the newer modules will have their version numbers appended to
>> their names, this way a user can build all the drm modules, and things
>> will just work. Hopefully we can get a 4.1.1 release out soon which
>> will do this. This will make the 4.0 -> 4.1 have to be a compile time
>> decision, but 4.1 -> 4.1.1 and higher will just coexist with each
>> other. I'm currently working out integrating this into the kernel
>> build, and I should hopefully have a patch for Linus and Alan soon.
>
>
> Would it not be a bit more robust to have a wrapper module that pulls in
> the correct one on demand? In other words, for the radeon, you would
> still have the radeon.o module, but it would determine which child
> module to load depending on the version of X that is requesting it. Thus
> XFree86 would not require any changes and the backwards compatibility
> would be maintained invisibly.
>
> John
>
No, because the 2D ddx module is the one doing all the versioning. It
doesn't tell the kernel its version number etc., but the ddx module gets
the version from the kernel, and fails if its the wrong one. If the
kernel was the one doing the checking, then your suggestiong would be a
nice way of handling it.

-Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.057 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site