Project

General

Profile

Actions
Copy link

Feature #549

open

We want to know the kernel version during processing

Added by Evgeny Novikov over 13 years ago. Updated over 12 years ago.

Status:
Open
Priority:
Normal
Assignee:
Evgeny Novikov
Category:
Infrastructure
Start date:
11/15/2010
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

This is needed for example to define model parts that are kernel depended.

Actions
Copy link
 #1

Updated by Evgeny Novikov over 13 years ago

I quickly find out where kernel version is placed :)
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>
Actions
Copy link
 #2

Updated by Alexey Khoroshilov over 13 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.

Actions
Copy link
 #3

Updated by Alexey Khoroshilov over 13 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.

Actions
Copy link
 #4

Updated by Pavel Shved over 13 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.

Actions
Copy link
 #5

Updated by Evgeny Novikov over 13 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...

Actions
Copy link
 #6

Updated by Evgeny Novikov over 13 years ago

  • Priority changed from Normal to High
I read a history of linux kernel versioning here http://en.wikipedia.org/wiki/Linux_kernel (Version numbering). Shortly from there:
  • "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."
Actions
Copy link
 #7

Updated by Evgeny Novikov over 13 years ago

Major from http://www.linfo.org/kernel_version_numbering.html:
  • "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."
Actions
Copy link
 #8

Updated by Evgeny Novikov over 13 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.

Actions
Copy link
 #9

Updated by Evgeny Novikov about 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

Actions
Copy link
 #10

Updated by Evgeny Novikov about 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.

Actions
Copy link
 #11

Updated by Pavel Shved over 12 years ago

  • Priority changed from High to Normal
Actions
Copy link

Also available in: Atom PDF