Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
1).. As newbie..i am not knowing on
HOW TO IDENTIFY a ".ko" is meant for which version of kernel ?;
is there any command that extracts the Version Information of the .KO file..
2) May be it is silly, but just want to clear the Gray point about the kernel version..
i have read somewhere about the kernel versioning, that the linux kernel version that ends with EVEN number is a stable one and
the ODD number is developmental version. (not sure it is applicable only to MAJOR number)
but recently i have seen in http://www.kernel.org as
2.6.29.3 as stable version .. this contradicts? can any one clarify me..
@ above
a .ko is meant for kernel version which u have compiled in module makefile of try to load it through insmod ./*.ko it will give the version no if its not correct . else its same as ur kernel version though which u can get through uname -a .
and that notion abt even no bein stable and odd being unstable is no longer applicable for the 2.6.x kernel series. all versions of 2.6.x are stable versions. btw u can make one module compiled for one version make to work for another kernel version by enabling MOD_VERSIONING support in the kernel options when compiling.
warm regards,
Ravi Kulkarni.
2.4 was stable, 2.5 was testing, 2.6 is stable
The old idea was dropped after some discussion with 2.6 - Linus hasn't (really) decided what will happen in future.
2.4 was stable, 2.5 was testing, 2.6 is stable
The old idea was dropped after some discussion with 2.6 - Linus hasn't (really) decided what will happen in future.
Yes thats right. I came across an email chain on kerneltrap.org when looking for this not long ago. Linus made this reply on that thread:
Quote:
I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back.
That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember.
So I would not dismiss (and have been thinking about starting) talk about a simple numbering reset (perhaps yearly), but the old model of 3-year developement trees is simply not coming back as far as I'm concerned.
In fact, I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on "features" any more, so why should we do version _numbering_ based on "features"?
For example, I don't see any individual feature that would merit a jump
from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps should be done by a time-based model too - matching how we actually do releases anyway.
So if the version were to be date-based, instead of releasing 2.6.26,
maybe we could have 2008.7 instead. Or just increment the major version
every decade, the middle version every year, and the minor version every time we make a release. Whatever.
But three-year development trees with a concurrent stable tree? Nope. Not going to happen.
Linus
So there you are. No decision on this yet, but I guess it will change eventually. I think its reasonably certian it won't be a 2.7, or a new stable 2.8.
but for the point (1)., when i insert a module in a kernel of different version it just says
Code:
# insmod *.ko
bridgedriver: disagrees about version of symbol struct_module
bridgedriver: disagrees about version of symbol struct_module
insmod: cannot insert 'bridgedriver.ko': invalid module format
also i am not sure.. for compiling this ".ko", which version of kernel is used...
so is there any way to identify the ".ko" is for X.X.X version of kernel!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.