Re: [RFC PATCH 3/5] linux-kernel-base: add support for Linux 3.x

[Phil Blundell <pb@pbcl.net>]

On Tue, 2011-06-21 at 21:10 +0200, Anders Darander wrote:
> If we keep the kernel_majorversion, we'll need to have something
> similar to this,
> as the major version up to 2.6 was determined by X.Y. From 3.0, only the first
> digit represents the major number; while the second digit (0 in 3.0)
> is equal to
> x in 2.6.x. Thus, the function to determine the major version has to
> return either
> 2.6 or 3.

Well, the thing is that OE's "kernelmajorversion" was always something
of an artificial construct.  It was introduced purely as a way of coping
with some of the differences between 2.4 and 2.6: this was primarily the
different module format, but it also happened to coincide with major
rewrites of the iPAQ and Zaurus kernels which were the main ones we were
using in OE at the time.  Returning "3" here isn't going to be helpful
since none of the classes will know what to do with that value: all they
ever do is compare it against either 2.4 or 2.6.  The exact form of
those tests has never been standardised, so there is a risk that you
might encounter

if [ "$KERNEL_MAJORVERSION" != "2.6" ]; then
  # must be 2.4!
fi

which would evidently lose quite badly if the major version were
suddenly to become 3.

Since there are no material differences between Linux 2.6 and Linux 3.0
that OE needs to be aware of, I think it would make most sense for
kernelmajorversion() to continue returning "2.6" for Linux 3.0 and
future versions if we did want to keep that mechanism.

However, since the whole purpose of the mechanism was to ease the
transition from 2.4 to 2.6, I am fairly confident that it can just be
deleted altogether if support for 2.4 is being removed. 

p.