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@xxxxxxxxxx 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@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@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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
