Bug 3950 - Xorg prints version numbers in wrong format for modules compiled for Xorg 6.99 & later
Summary: Xorg prints version numbers in wrong format for modules compiled for Xorg 6.9...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: All All
: high normal
Assignee: Alan Coopersmith
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1690
  Show dependency treegraph
 
Reported: 2005-08-02 09:09 UTC by Alan Coopersmith
Modified: 2005-08-08 01:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Alan Coopersmith 2005-08-02 09:09:42 UTC
When testing a modular built Xserver, I noticed the module versions in my error
log were strange:

(II) Module vesa: vendor="X.Org Foundation"
        compiled for 4.22.7H|, module version = 1.0.0

Checking in the source I found the versions were set right in the modules,
as  XORG_VERSION_CURRENT had been expanded to the value for 6.99.99.900:
( ( ( 6 ) * 10000000 ) + ( ( 99 ) * 100000 ) + ( ( 99 ) * 1000 ) + 900 ),

but the code to print the version number in hw/xfree86/loader/loadmod.c was
interpreting it incorrectly, since the resulting value of 69999900 is now
greater than  (4 << 24), aka 67108864, so it treats it as an XFree86 4.0.x
version number and mangles it as shown.

We need to decide if we still care about printing correct versions for 
modules built for XFree86 4.0.x or figure out a way to correctly print
those and 6.99/7.x version numbers.
Comment 1 Adam Jackson 2005-08-05 12:11:22 UTC
We should be able to handle the old numbers correctly.

The 4.0.x macro, for reference, was:

#define XF86_VERSION_NUMERIC(major,minor,subminor,beta,alpha)  \
  ((((((((major << 7) | minor) << 7) | subminor) << 5) | beta) << 5) | alpha)

This scheme was only ever used for modules in the 4.0.x series, so it defines a
range of values (4 << 24) through (4 << 24 + 1 << 17 - 1) where the version
number is "old style".  That corresponds to 67108864 through 67239936.  In the
new numbering scheme that would be 6.71.8.764 through 6.72.39.934.  We can
safely say that we will never release an X11R6.71 or 6.72, since the end of the
R6 series is 6.9.  Therefore numbers in that range are unambiguous.

I have at least one future project that wants the ability to load 4.0.x modules,
so I would like to see us handle the old-style range correctly.
Comment 2 Adam Jackson 2005-08-08 05:56:35 UTC
Created attachment 3289 [details] [review]
CharToUnicode changes

trivial fix
Comment 3 Adam Jackson 2005-08-08 06:00:48 UTC
Created attachment 3290 [details] [review]
_mesa wrappers for libc functions

this time for sure (<< has lower precedence than +, need more parens)
Comment 4 Alan Coopersmith 2005-08-09 11:15:50 UTC
Looks pretty much like the fix I had written but hadn't gotten around to testing
until this evening.   (Except I left out the "- 1", figuring it wasn't needed with
the < instead of <= .)

I just tested on the same system that was reporting the 4.22.7H| version numbers,
and it's now reporting:
        compiled for 6.99.99.900, module version = 1.2.0
so I'll go ahead and commit.

(I also couldn't find anywhere else this needs to be fixed.)
Comment 5 Alan Coopersmith 2005-08-09 11:20:19 UTC
Fix committed to CVS head:

CVSROOT:	/cvs/xorg
Module name:	xc
Changes by:	alanc@gabe.freedesktop.org	05/08/08 18:18:04

Log message:
  2005-08-08  Alan Coopersmith  <alan.coopersmith@sun.com>
  
  	* programs/Xserver/hw/xfree86/loader/loadmod.c
  	Bug #3950 <https://bugs.freedesktop.org/show_bug.cgi?id=3950>
  	Xorg prints version numbers in wrong format for modules
  	compiled for Xorg 6.99 & later (Adam Jackson & Alan Coopersmith)

Modified files:
      xc/programs/Xserver/hw/xfree86/loader/:
        loadmod.c 
      ./:
        ChangeLog 
  
  Revision      Changes    Path
  1.8           +7 -1      xc/programs/Xserver/hw/xfree86/loader/loadmod.c
  1.1192        +7 -0      xc/ChangeLog



Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.