On Wed, Jun 22, 2011 at 12:22, Phil Blundell <[email protected]> wrote: > 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
I assumed that the reason was that; and it's nice to get a better grip of the older history. (At that time I was more concerned with Buildroot and uCLinux). > 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. Yes, and that's why I completely removed the tests in the bbclasses that I've touch sofar. > 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. Sounds good. I'll grep through a few more classes to see if the tests seems to occur in more places. Unless I find that the major version is used for something else, I'll remove it. Regards, Anders _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
