Long-term support initiative 3.4 kernel released

[Posted January 22, 2013 by corbet]

The Long-Term Support Initiative helps to provide support for selected kernels for a two-year period. But the project has also intended to release additional kernels aimed at the needs of the consumer electronics industry. That has come about with the announcement of the release of the LTSI 3.4 kernel. It is based on 3.4.25, but with an improved CMA memory allocator, the out-of-tree AF_BUS protocol implementation, and a backport of the CoDel queue management algorithm, along with various hardware enablement patches and other useful bits of code.

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 16:25 UTC (Tue) by arjan (subscriber, #36785) [Link] (6 responses)

hmmmm stable kernels adding kernel ABI/API's (AF_DBUS) that are not even in upstream yet? That sounds like a disaster waiting to happen...

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 17:13 UTC (Tue) by bluss (guest, #47454) [Link] (5 responses)

Maybe it's natural if a single central person blocks progress on a feature.

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 17:17 UTC (Tue) by arjan (subscriber, #36785) [Link] (4 responses)

NO it is absolutely NOT natural.
Stable kernels should not add non-upstream ABI/APIs

bypassing the upstream process is not a valid option.

this is to the level where this guy should be stripped from it's kernel.org official status

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 17:25 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

LTSI is hosted by the Linux Foundation, not kernel.org.

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 18:33 UTC (Tue) by Jonno (subscriber, #49613) [Link] (2 responses)

Remember, this is essentially CEWG's (Consumer Electronics Work Group) response to the Android kernel, intended for device manufacturers and other embedded developers to do their SoC work on when targeting non-Android Linux.

As such, I'm rather surprised at the *low* amount of non-upstream patches included...

Also, this isn't really something new, they have been doing this as a git branch of first 3.0 and later 3.4 since August 2011, they have just never bothered doing releases before (as everyone using it would be doing their own development in git on top of it anyway).

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 18:57 UTC (Tue) by arjan (subscriber, #36785) [Link] (1 responses)

I don't mind non-upstream patches nearly as much as non-stream API/ABIs.
The latter means userspace software gets written assuming "number X means Y"... which won't be the case in upstream, when number X gets reused.. say for AF_FOO instead of AF_DBUS.
And then you get an application compatibility nightmare.

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 19:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, reserve a number for it, then. Or be prepared to repeat the whole Android saga.

Long-term support initiative 3.4 kernel released

Posted Jan 22, 2013 19:39 UTC (Tue) by butlerm (subscriber, #13312) [Link] (6 responses)

So is there a good reason why the mainstream kernel hasn't accepted such a broadly useful feature as AF_BUS yet? Or something similar, like multicast Unix socket capability?

Reading the article, the objections seem to amount to little more than stubborness. I am in charge so you can't have this feature, no matter how useful it is. What kind of operating system wouldn't benefit from reliable multicast interprocess communication?

the point is that this violates the charter for -stable

Posted Jan 22, 2013 20:42 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

That's not the main point here.

The main point is that this violates the charter for -stable releases.

Specifically, -stable releases are not supposed to have any fixes in them that are not in upstream (or at least that are not fixed in some other way in upstream if the exact fix won't work)

This is to prevent the -stable branches from becoming dead-ends where people cannot upgrade from 2.x.y to 2.x+n.z because 2.x+n doesn't implement some feature that was put in 2.x.y

Adding an API/ABI like this is exactly what this policy was intended to prevent

At this point, 2.4.x is no longer a -stable branch, it's a full fork.

the point is that this violates the charter for -stable

Posted Jan 22, 2013 20:46 UTC (Tue) by corbet (editor, #1) [Link]

LTSI was never meant to be a stable branch; it is an independent kernel maintained for a specific industry. The inclusion of backported features and such was always part of the plan. The hope is to at least get various vendors working from the same kernel with added goodies and part of the process of getting them closer to upstream.

the point is that this violates the charter for -stable

Posted Jan 22, 2013 23:50 UTC (Tue) by chrisV (guest, #43417) [Link]

LTSI has got nothing to do with 3.4-stable, which continues to be maintained as a blessed long-term kernel, and is targeted to be supported until the end of 2014. 3.4.27 came out two days ago.

the point is that this violates the charter for -stable

Posted Jan 23, 2013 9:45 UTC (Wed) by kugel (subscriber, #70540) [Link]

I was thinking the same, until I realized that I mixed up LTSI with kernel.org's longterm/stable release.

I guess for LTSI it's fine to drift away, and create a bit of pressure to upstream highly desired changes.

the point is that this violates the charter for -stable

Posted Jan 23, 2013 14:51 UTC (Wed) by butlerm (subscriber, #13312) [Link] (1 responses)

This isn't a "stable" branch, but it certainly does present an ABI issue. Something that is this widely used should have a slot reserved in the kernel ABI even if the mainstream kernel developers are undecided about whether to incorporate it themselves. That handily solves the ABI issue.

The API issue is easily handled by having applications use a library that has fallback means of communication in case the running kernel doesn't implement the interface concerned.

the point is that this violates the charter for -stable

Posted Jan 24, 2013 10:17 UTC (Thu) by khim (subscriber, #9252) [Link]

Yup. I'm surprised it's that controversial. Come on: Linus widely said that Linux will never support STREAMS yet we have syscall numbers dedicated to that support in mainstream Linux.

If it's used in relatively large number of installations it deserves at least numbers reserved in mainline kernel.