kernel versionning problem

Dave Jones davej at redhat.com
Sun Jan 28 19:48:57 UTC 2007


On Tue, Jan 23, 2007 at 03:43:51AM +0530, Rahul Sundaram wrote:
 > Tanguy Eric wrote:
 > > Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
 > >> Tanguy Eric wrote:
 > >>> I sent this message to fedora-list at redhat.com but i had no reaction so i
 > >>> try also the devel one because i find this is problem we have to solve
 > >>> for the core and extras merge, no ?
 > >>>
 > >>> I'm tired to have problems with rt2500 driver at each new fedora kernel
 > >>> release because the versionning seems to not follow standards :
 > >>> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
 > >>>
 > >>> What do you think about this ?
 > >>>
 > >>> Someone have similar problems with other modules ?
 > >> This one is going all the way up to Linus since apparently he prefers 
 > >> the current naming. See 
 > >> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111 
 > >> for the glorious details.
 > >>
 > >> Rahul
 > >>
 > > Ok but my problem is not really the kernel name but how a driver can
 > > detect correctly the kernel version and eventually the backported patch
 > > to compile fine ...
 > 
 > Yes. The name of the kernel is directly related to that issue.

No, it isn't.
The results of the macro being checked by out of tree drivers doesn't
take into consideration point releases, so it reports 2.6.19 on 2.6.19.2
just like it does on an upstream kernel (unsurprising, as we don't change it).
This is not a Fedora problem, but a problem in the code of the out
of tree driver.

(14:44:19:davej at gelk:19.2)$ cat include/linux/version.h 
#define LINUX_VERSION_CODE 132627
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

(14:45:42:davej at gelk:linux-2.6.19.noarch)$ cat include/linux/version.h 
#define LINUX_VERSION_CODE 132627
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))


Now, it *should* be changed to support the 4th sublevel, but doing so
would probably break a ton of out of tree drivers, and would probably
be seen as another problem of "Fedora developers making kernels that don't conform to standards".

If this change were to happen, *then* it would be a problem
that we ship 2.6.19.2 yet call it 2.6.19, but given that upstream
is broken, we are no moreso.

It's way easier to hide incompetence when there's someone else to blame,
but in this case, we're doing absolutely nothing wrong.

		Dave

-- 
http://www.codemonkey.org.uk




More information about the fedora-devel-list mailing list