Carsten Munk had written, on 12/14/2010 03:45 PM, the following:
btw, I think this discussion is better on meego-kernel ML.
Just noticed that http://wiki.meego.com/Core_OS_Program/Kernel_policy
Overall, meaning of upstream is confusing to me at least - in my
terminology upstream kernel == kernel.org which I think is wiki's spirit
is as well. How MeeGo kernel policy maps to kernel.org and stable tree
cycles is missing me though :( - The intent and benefits of MeeGo kernel
needing to maintain as few patches as possible is obvious - just
confusing from a kernel developer perspective - "I want to enable MeeGo
for platform X - what should I do?"
1. MeeGo will ship with one 'reference kernel', that will have one shared
codebase
between all the devices it supports (with different configuration files). This
kernel will be close to the upstream kernel with very few patches applied to it,
and the version will be chosen by the architecture team such that the kernel is
relatively recent, while still allowing for a reasonable stabilization period
before a MeeGo release ships.
Today's "reference kernel" == kernel main package I believe = 2.6.35
(not exactly something we'd call recent). IMHO, relative sounds pretty
much subjective in that context. What is the criteria for selection of
lets say MeeGo 1.3 "reference kernel"? stable tree?
What does this mean to today's kernel-dev and it's role in MeeGo?
2. For a platform to be part of this `reference kernel', the supporting adaptation
code (drivers/etc) needs to already be in the upstream kernel for the version
that the reference kernel uses. It's assumed that such a platform will only
need a low number of small patches to fix the occasional bug.
Bottom line - if your platform and feature is not in mainline at the
time of "reference kernel", vendor X has no choice but to create a
kernel-adaptation kernel. If the "relatively recent" means something
like 2.6.35, It is going to force a plethora of kernel-adaptation
kernels with backported kernel patches - number could vary depending on
platform complexity. We then state in point 7 "all adaptation kernels
must be within two kernel releases of the reference kernel" - aka, I
could have a kernel-adaptation based on 2.6.33!
[1]
.32 seems to have more recent maintenance compared to .33
using Meego 1.2 release timeline[2] as an example:
2010-09-30 - we decide that 2.6.35 kernel is reference
2011-04-27 - we make MeeGo 1.2 release
6 months ~= 2 kernel.org release cycles.
I mean we are looking for potential kernel .33 all the way to .38 or
even later kernel (If we consider kernel-dev) - that is a pretty long
way for ABIs & features to be maintained despite all the best intentions.
Finally, what does this mean for community(not vendor) maintained kernel?
Ref:
[1]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=heads
[2] http://wiki.meego.com/Release_Engineering/Plans/1.2
--
Regards,
Nishanth Menon
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
