On Tue, Dec 14, 2010 at 03:14:06PM -0800, Arjan van de Ven wrote: > On 12/14/2010 3:10 PM, Nishanth Menon wrote: >> Arjan van de Ven had written, on 12/14/2010 04:55 PM, the following: >> [...] >>>>> 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). >>> >>> in this context, assume 1.2 to ship with a 2.6.37 kernel as reference >>> kernel. >> Do you intend to indicate that the last formal release will be chosen >> as reference kernel? > > a relatively current release will be chosen yes. Now "last formal" is a > hard term; since 2.6.38 likely will be out before 1.2 ships, 2.6.37 is > clearly not the last formal release at the time of ship. > (but 2.6.38 will be out very shortly before 1.2 ships, so picking 2.6.38 > would not be the smartest thing in the world) > >> >>> >>>> 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? >>> >>> the architects will eventually decide that after discussion on the >>> architecture list. But doing very basic math on schedule and at some >>> dried tea-leaves... 2.6.39 would not be out of the question for 1.3, >>> unless Linus would be extremely late with 2.6.38, while 2.6.40 would >>> be on the super aggressive side. >> Makes me wonder if the discussion is to reiterate the previous statement? > > ??? > picking versions is mostly looking at a calendar... not deep long > discussions. > >>>> >>>> What does this mean to today's kernel-dev and it's role in MeeGo? >>> >>> the need for kernel-dev would be absorbed more or less by being able >>> to have the reference kernel follow upstream more aggressive, >>> while vendors that aren't as Linux-savy, and have a strong desire to >>> stay on an older kernel, now can do so. >> upto -2 version of the kernel on the MeeGo release - How do we intend to: >> "MeeGo compliance profile will have a set of kernel configuration >> options that are required to be set, in order to provide a consistent >> ABI and consistent functionality" >> >> Just config option is no real guarantee rt? > > it also means that apps can't assume anything newer than the "minus two" > kernel. > > >> >> Also missing is this: >>> Finally, what does this mean for community(not vendor) maintained >>> kernel? >> > > I don't see the difference between a vendor maintaining a kernel package > and a community of people maintaining a kernel package....
Being involved in a relatively small OSS community around Archos portable media players I can tell you that it makes a huge difference for us. But I'm not even sure why I'm jumping into this discussion. Most of our projects are doomed to stick to whatever kernel was adapted for the given hardware. Why? Because they take some TI BSP/PSP kernel and adapt it to their device, resulting into something that is nowhere near anything upstream. Yes that is something we don't like, but seriously WHAT can we do? We are just a small project and so far haven't managed to get an army of Kernel developers to adapt an upstream kernel or upstream all possible changes for us. We have to accept this as a given. Still we want to run e.g. MeeGo on those devices (and it does!). I know that this is going whoooosh as we will never aim to have an official device for MeeGo. Still we want to actively work with the MeeGo community and also help enable other hardware. We currently do WRT BMC 5616. My perception is that this 'has to run vanilla kernel XYZ' is simply missing the point and ability of most open source projects that center around some commercial hardware where the Vendor was kind enough to abide to the GPL and release a working set of sources. (Instead of holding back for a year or more until the device is oboleted) Bottom line: I perceive those things as a deterrent towards all projects like ours. Go on IRC and ask a question. One of the first questions/suggestions will be 'run the MeeGo kernel'. That's where people either leave or are strong enough to ignore this. Yes sucks to be us, go ahead and frown upon us. Still we're here. just my 0,02€ Thomas _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
