Messages in this thread | | | Date | Tue, 16 Aug 2011 16:01:57 -0700 | Subject | Re: Future of the -longterm kernel releases (i.e. how we pick them). | From | Tim Bird <> |
| |
>Greg KH wrote: > To keep this all out in the open, let's figure out what to do here. > Consumer devices have a 1-2 year lifespan, and want and need the > experience of the kernel community maintaining their "base" kernel for > them. There is no real "enterprise" embedded distro out there from what > I can see. montaVista and WindRiver have some offerings in this area, but > they are not that widely used and are usually more "deep embedded". > There's also talk that the CELF group and Linaro are wanting to do > something on a "longterm" basis, and are fishing around for how to > properly handle this with the community to share the workload. Android > also is another huge player here, upgrading their kernel every major > release, and they could use the support of a longterm kernel as well.
Well I certainly hope that there's more participation on sharing the workload by embedded companies than there has historically been. I'm not at LinuxCon this week, but I want to follow up with you (maybe at KS?) on good ways that CE companies can help with this effort.
> Proposal: > > Here's a first cut at a proposal, let me know if you like it, hate it, > would work for you and your company, or not at all: > > - a new -longterm kernel is picked every year. > - a -longterm kernel is maintained for 2 years and then dropped. > - -stable kernels keep the same schedule that they have been (dropping > the last one after a new release happens.) These releases are best > for products that require new hardware updates (desktop distros, > community distros, fast-moving embedded distros (like Yocto)). > - the normal -stable rules apply to these -longterm kernels as described > in Documentation/stable_kernel_rules.txt > > This means that there are 2 -longterm kernels being maintained at the > same time, and one -stable kernel. I'm volunteering to do this work, as > it's pretty much what I'm doing today anyway, and I have all of the > scripts and workflow down.
This all sounds great to me. As you know CEWG (formerly CELF) is very interested in supporting LTS work. What you describe would be a good base for what we envision.
That said, I echo the concerns about version selection. It would be good to have a "settle" period longer than 1 stable release for selecting a kernel (but then again, we don't want to wait too long to pick each longterm release).
Rolling, overlapping, longterm versions seems like a nice idea. I like the idea of looking for a volunteer to continue maintenance after 2 years, and if none is found dropping the release. That way, someone can step up if there is continued interest in a particular longterm version.
Also, the more people using a particular LTS kernel, the better. In the past the embedded guys didn't coordinate well enough with other parties. If we could get enterprise, desktop and embedded on a single LT release, that would be really nice. I'm not sure how you're keeping track of interested parties, but if there's a mailing list (besides 'stable') let me know so I can sign up.
With regard to version selection, I know different companies will have different versions they'd like to see selected. Having consensus on a version is more important than the particular version chosen.
Having said that, here are some (non-BSP) things we look at for selecting kernel versions at Sony:
One specific issue I have is support for PREEMPT_RT, so that's a big factor in selecting Sony kernel versions. Thus, coordinating with the RT patchset kernel versions is important to me. Currently that would mean 3.0 is a good candidate.
The other major out-of-tree patches we usually integrate are 1) Android 2) LTTng, but I've heard that this might soon be buildable as a loadable module (eliminating the need for any patch integration).
Thanks, -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |