Re: XFree86 module compatibility?
On Tue, 4 Mar 2003, Kendall Bennett wrote: I know I have asked this before, but I can't seem to find my emails and the mailing list archive does not seem to be responding. What sort of back/forward compatibility is there with the XFree86 driver modules? From memory last time I tested this, if I compile a 4.2.0 module it will work with any version of 4.2.x, but it will fail to load on 4.3.x or 4.1.x. So right now we are thinking of building modules for 4.0.x, 4.1.x, 4.2.x and 4.3.x and shipping all four modules with our installer (which will auto choose which one to install). Is that the correct approach? Or should we be building modules for each released version of XFree86 (ie: 4.1.0, 4.1.2, 4.1.3, 4.2.0, 4.2.1 etc)? The compatibility we strive for (but admittedly don't always accomplish) is best expressed as Version(module) = Version(core binary) There are also inter-module dependencies to consider. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
On Wed, 5 Mar 2003, Marc Aurele La France wrote: On Wed, 5 Mar 2003, Kendall Bennett wrote: Is that the correct approach? Or should we be building modules for each released version of XFree86 (ie: 4.1.0, 4.1.2, 4.1.3, 4.2.0, 4.2.1 etc)? The compatibility we strive for (but admittedly don't always accomplish) is best expressed as Version(module) = Version(core binary) There are also inter-module dependencies to consider. So basically we should be able to compile with say 4.1.0 and have our module run on all greater versions of 4.x.0 right? Obviously YMMV, so we should probably test this. The downside of course is that we would much prefer to be compiling with the latest version of XFree86 rather than a backlevel version for our modules, but if we do that we will not be able to support older versions. Hence I am thinking that I should compile against the tip level in each sub version. Ie: 4.0.0, 4.1.0, 4.2.0, 4.3.0 etc so it will work with each minor revision of that branch (ie: 4.2.0 works with 4.2.1 through 4.2.99 which I already know). However if say I upgrade our development tree to 4.3.1, does that mean that the 4.3.1 driver will fail to load on a 4.3.0 install? The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Marc Aurele La France [EMAIL PROTECTED] wrote: The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Right, we plan to test with every version of XFree86 to ensure compatibility (along with tons of Linux distros; ugh). We would like to support all versions of XFree86 with our module, and we have no problem building different modules as necessary to support those versions. What I am trying to figure out is what the smallest set of module versions I can build to ensure compatibility. It would be nice if I could build a 4.0.3 module and have it work with 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all 4.0.x versions, right? Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
On Wed, 5 Mar 2003, Kendall Bennett wrote: Marc Aurele La France [EMAIL PROTECTED] wrote: The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Right, we plan to test with every version of XFree86 to ensure compatibility (along with tons of Linux distros; ugh). We would like to support all versions of XFree86 with our module, and we have no problem building different modules as necessary to support those versions. What I am trying to figure out is what the smallest set of module versions I can build to ensure compatibility. It would be nice if I could build a 4.0.3 module and have it work with 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all 4.0.x versions, right? Nothing will work with all 4.0.x versions. 4.0.0 XAA isn't binary compatible with 4.0.1 and newer XAAs. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Marc Aurele La France [EMAIL PROTECTED] wrote: % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on. If that means 4.1.0, then that means 4.1.0. This does % not absolve you of the responsibility to ensure the thus-generated binary % works with later core binary versions. % % Allow me to qualify that... % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on and provides the suport base you are willing to live % % with. If that means 4.1.0, then that means 4.1.0. This does not absolve % % you of the responsibility to ensure the thus-generated binary works with % later core binary versions. % % Right, we plan to test with every version of XFree86 to ensure % compatibility (along with tons of Linux distros; ugh). We would like to % support all versions of XFree86 with our module, and we have no problem % building different modules as necessary to support those versions. What I % am trying to figure out is what the smallest set of module versions I can % build to ensure compatibility. We fight the tons of Linux distros; ugh battle at work. Rather, we quickly decided that we *couldn't* fight that battle and win, so we chose a double handful of distributions that: ° We believe represents significant shares of the installed Linux base ° Complements the strengths of our developers, QA personnel, writers, and in-house Linux users (we're a mixed Linux/Windows shop) Off the top of my head, we chose 2 recent Linux-Mandrake releases, the last 3 Red Hat Linux releases, the most recent SuSE release, and Debian Potato and Woody. I suppose we'd add your favorite distro here if a customer waved enough shekels at us to make the QA effort worthwhile. % It would be nice if I could build a 4.0.3 module and have it work with % 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all % 4.0.x versions, right? I'd venture to say you just have to test against the N releases you think you can afford or have the resources to support. Kurt -- God may be subtle, but He isn't plain mean. -- Albert Einstein ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Kendall, You should also test against different distributions, different compilers (gcc 3.2.x versus 2.95) and different C libraries. In particular, modules compiled with gcc 2.95 might not work with XFree86 compiled with gcc 3.2.x and vice versa.. best Vladimir Dergachev ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % I know I have asked this before, but I can't seem to find my emails and % the mailing list archive does not seem to be responding. % % What sort of back/forward compatibility is there with the XFree86 driver % modules? From memory last time I tested this, if I compile a 4.2.0 module % it will work with any version of 4.2.x, but it will fail to load on 4.3.x % or 4.1.x. So right now we are thinking of building modules for 4.0.x, % 4.1.x, 4.2.x and 4.3.x and shipping all four modules with our installer % (which will auto choose which one to install). Hmm. I installed 4.3.0 on a crash test dummy at work today. I had the mga_hal.o module from Matrox for 4.2.mumble. Copied it into place, started X, and it seemed to load without incident - no untoward messages in the log files and neither the monitor nor the video card went up in smoke. ;-) More generally, where might I might information on determining binary compatibility, or lack thereof, between module version and XFree releases? Kurt -- With a gentleman I try to be a gentleman and a half, and with a fraud I try to be a fraud and a half. -- Otto von Bismark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Kurt Wall [EMAIL PROTECTED] wrote: Hmm. I installed 4.3.0 on a crash test dummy at work today. I had the mga_hal.o module from Matrox for 4.2.mumble. Copied it into place, started X, and it seemed to load without incident - no untoward messages in the log files and neither the monitor nor the video card went up in smoke. ;-) Interesting. It is possible that the binary compatibility is for forward releases only. ie: 4.3.0 can run 4.2.x and 4.1.x etc binaries, but 4.1.x will not allow loading of future driver binaries Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
