[lkml]   [2011]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Future of the -longterm kernel releases (i.e. how we pick them).
    >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).

    -- Tim
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-08-17 01:05    [W:0.050 / U:6.148 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site