Feature #549
openWe want to know the kernel version during processing
Added by Evgeny Novikov about 14 years ago. Updated about 13 years ago.
0%
Description
This is needed for example to define model parts that are kernel depended.
Updated by Evgeny Novikov about 14 years ago
This is made at the beginning of each general kernel Makefile. For example:
- linux-2.6.31.6
VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 31 EXTRAVERSION = .6 NAME = Man-Eating Seals of Antiquity
- linux-2.6.35.7
VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 35 EXTRAVERSION = .7 NAME = Yokohama
So I think that we just want to pass these options trough commands files as defines like this:<opt>-DVERSION = 2</opt>
Updated by Alexey Khoroshilov about 14 years ago
I do not like the idea to depend on kernel version.
Yes, we always said that kernel core API is not stable and we have to follow its evolution. But we should try to adapt to a kernel looking at its features and not looking at its version.
The reason is it is difficult to build a map between kernel versions and kernel features keeping in mind a number of non-vanilla kernel distributors.
Updated by Alexey Khoroshilov about 14 years ago
So I think that we just want to pass these options trough commands files as defines like this:
<opt>-DVERSION = 2</opt>
VERSION is too generic identifier to be used safely.
Updated by Pavel Shved about 14 years ago
Is depending on version reliable? I really doubt that the commit, which introduced changes to _raw_spin_lock in bug #403 also changed the version number.
Updated by Evgeny Novikov about 14 years ago
- Priority changed from Immediate to Normal
As Alexey said such dependency isn't safe since there is no straight dependency between kernel 'version' and kernel API. For example, redhat may add some part of the newest kernel API to its old kernels adding a new non standardized EXTRAVERSION.
So indeed we have to avoid dependency on kernel versions in models if it's possible. But we may want to know kernel version sometimes...
Updated by Evgeny Novikov about 14 years ago
- Priority changed from Normal to High
- "The first two numbers became largely irrelevant, and the third number is the actual version of the kernel. The fourth number accounts for bug and security fixes (only) to the kernel version."
- "Regular development pre-releases are titled release candidates, which is indicated by appending the suffix 'rc' to the kernel version, followed by an ordinal number."
- "Also, sometimes the version will have a suffix such as 'tip', indicating another development branch, usually (but not always) the initials of a person who made it. For example, 'ck' stands for Con Kolivas, 'ac' stands for Alan Cox, etc. Sometimes, the letters are related to the primary development area of the branch the kernel is built from, for example, 'wl' indicates a wireless networking test build. Also, distributors may have their own suffixes with different numbering systems and for back-ports to their "Enterprise" (i.e. stable but older) distribution versions."
Updated by Evgeny Novikov about 14 years ago
- "Linux kernels are now identified by a set of four numbers, sometimes supplemented by several additional characters."
- "The first number denotes the kernel version. It is changed least frequently, and only when truly major changes in the concept and the code of the kernel occur."
- "The second number denotes the major revision of the kernel version."
- "The third number indicates the minor revision of the kernel. It is only changed when new features or new drivers are added."
- "The fourth number represents corrections, such as security patches and bug (i.e., error) fixes."
- "Sometimes the four numbers will be followed by several letters, such as rc1, ac, ck and mm. The letters rc (followed by a number) refer to a release candidate and thus indicate a non-official release. Other letters usually indicate the person responsible for that release, such as Alan Cox, Con Kolivas and Andrew Morton."
Updated by Evgeny Novikov about 14 years ago
- Priority changed from High to Normal
I suggest that this unneeded functionality may just bring some new errors and take a lot of time to make all working. So we should do it just when it'll be really needed.
Updated by Evgeny Novikov over 13 years ago
Just store some useful for this topic links to close them in my browser:
http://books.google.ru/books?id=vxBjXwgkkWIC&pg=PA351&lpg=PA351&dq=redhat+kernel+version+numbering&source=bl&ots=BI6OLbFB9b&sig=rMV2k_8bYcHbl-rXDACdCghpeMs&hl=ru&ei=Uk_hTLXbFI-bOom_xOwO&sa=X&oi=book_result&ct=result&resnum=10&sqi=2&ved=0CGcQ6AEwCQ#v=onepage&q&f=false http://www.intersectalliance.com/projects/Snare/Documentation/Kernel-Build-Howto.txt http://lists.opensuse.org/opensuse-kernel/2010-07/msg00014.html
Updated by Evgeny Novikov over 13 years ago
- Priority changed from Normal to High
Give a higher priority to this bug since it may be very useful for good model test cases writing.