From: Pavel Machek <pavel@ucw.cz>
To: Theodore Ts'o <tytso@mit.edu>,
Richard Weinberger <richard.weinberger@gmail.com>,
"Enrico Weigelt, metux IT consult" <weigelt@melag.de>,
"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
"backports@vger.kernel.org" <backports@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: Uses of Linux backports in the industry
Date: Tue, 23 Jun 2015 20:49:57 +0200 [thread overview]
Message-ID: <20150623184957.GB26150@amd> (raw)
In-Reply-To: <20150529173609.GF18540@thunk.org>
On Fri 2015-05-29 13:36:09, Theodore Ts'o wrote:
> On Fri, May 29, 2015 at 05:01:00PM +0200, Richard Weinberger wrote:
> > On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
> > <weigelt@melag.de> wrote:
> > > Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
> > > Actually, I really wonder why folks are sticking to ancient kernels on
> > > newer hardware.
> >
> > Enterprise distribution kernels. Or "special" kernels like PREEMPT_RT.
> > Sometimes the vendor BSP is that horrid that a customer cannot afford
> > to forward port it
> > but wants recent stuff. So you need to backport...
>
> Yep. The technique I used for the backporting ext4 encryption into
> the 3.10 android-common git tree in AOSP was to drop in the 3.18
> versions of fs/ext4 and fs/jbd2 into the 3.10 tree (along with the
> associaed include files in include/linux and include/trace/events, of
> course), and then fix things up until they built correctly (using
> cherry-picks and in some cases, reverting some changes in the 3.18
> version of fs/ext4). After I was sure the transplant of the 3.18
> version of ext4 had "taken" correctly, with no test regressions, only
> then did I cherry-pick all of the ext4 encryption changes on top of
> 3.10.
>
> The backport of ext4 encryption to the 3.18 version of android-common
> should be much easier. :-) Unfortunately, I also have to do a
> backport to the 3.14 android-common branch as well. <sigh>
>
> Yes, it's ugly, but there still are some SOC and drivers that aren't
> available on newer kernels. Basically, the handset vendors need to
> lean a lot harder on the SOC and other peripheral (cell radios, GPS,
> etc., etc.). :-(
Actually, what we really want is chip vendors to clean up the
interfaces, and merge their changes upstream... Perhaps we'll be able
to install normal distros on cellphones one day...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe backports" in
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: "Theodore Ts'o" <tytso@mit.edu>,
Richard Weinberger <richard.weinberger@gmail.com>,
"Enrico Weigelt, metux IT consult" <weigelt@melag.de>,
"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
"backports@vger.kernel.org" <backports@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: Uses of Linux backports in the industry
Date: Tue, 23 Jun 2015 20:49:57 +0200 [thread overview]
Message-ID: <20150623184957.GB26150@amd> (raw)
In-Reply-To: <20150529173609.GF18540@thunk.org>
On Fri 2015-05-29 13:36:09, Theodore Ts'o wrote:
> On Fri, May 29, 2015 at 05:01:00PM +0200, Richard Weinberger wrote:
> > On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
> > <weigelt@melag.de> wrote:
> > > Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
> > > Actually, I really wonder why folks are sticking to ancient kernels on
> > > newer hardware.
> >
> > Enterprise distribution kernels. Or "special" kernels like PREEMPT_RT.
> > Sometimes the vendor BSP is that horrid that a customer cannot afford
> > to forward port it
> > but wants recent stuff. So you need to backport...
>
> Yep. The technique I used for the backporting ext4 encryption into
> the 3.10 android-common git tree in AOSP was to drop in the 3.18
> versions of fs/ext4 and fs/jbd2 into the 3.10 tree (along with the
> associaed include files in include/linux and include/trace/events, of
> course), and then fix things up until they built correctly (using
> cherry-picks and in some cases, reverting some changes in the 3.18
> version of fs/ext4). After I was sure the transplant of the 3.18
> version of ext4 had "taken" correctly, with no test regressions, only
> then did I cherry-pick all of the ext4 encryption changes on top of
> 3.10.
>
> The backport of ext4 encryption to the 3.18 version of android-common
> should be much easier. :-) Unfortunately, I also have to do a
> backport to the 3.14 android-common branch as well. <sigh>
>
> Yes, it's ugly, but there still are some SOC and drivers that aren't
> available on newer kernels. Basically, the handset vendors need to
> lean a lot harder on the SOC and other peripheral (cell radios, GPS,
> etc., etc.). :-(
Actually, what we really want is chip vendors to clean up the
interfaces, and merge their changes upstream... Perhaps we'll be able
to install normal distros on cellphones one day...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2015-06-23 18:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 2:54 Uses of Linux backports in the industry Luis R. Rodriguez
2015-05-29 7:00 ` Johannes Berg
2015-05-29 8:08 ` Arend van Spriel
2015-05-29 8:29 ` Julia Lawall
2015-05-29 16:41 ` Arend van Spriel
2015-05-29 16:33 ` Luis R. Rodriguez
2015-05-29 18:47 ` Johannes Berg
2015-05-29 14:53 ` Enrico Weigelt, metux IT consult
2015-05-29 15:01 ` Richard Weinberger
2015-05-29 17:36 ` Theodore Ts'o
2015-05-29 17:51 ` Luis R. Rodriguez
2015-06-23 18:49 ` Pavel Machek [this message]
2015-06-23 18:49 ` Pavel Machek
2015-06-24 9:12 ` Enrico Weigelt, metux IT consult
2015-06-24 9:12 ` Enrico Weigelt, metux IT consult
2015-06-24 9:09 ` Enrico Weigelt, metux IT consult
2015-06-24 9:09 ` Enrico Weigelt, metux IT consult
2015-06-24 9:19 ` Richard Weinberger
2015-06-24 9:19 ` Richard Weinberger
2015-06-24 9:55 ` Enrico Weigelt, metux IT consult
2015-06-24 9:55 ` Enrico Weigelt, metux IT consult
2015-06-24 10:18 ` Richard Weinberger
2015-06-24 10:18 ` Richard Weinberger
2015-06-01 18:50 ` Felix Fietkau
2015-06-01 20:03 ` Julia Lawall
2015-06-24 10:13 ` Enrico Weigelt, metux IT consult
2015-06-24 10:13 ` Enrico Weigelt, metux IT consult
2015-06-02 19:05 ` Szymon Janc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150623184957.GB26150@amd \
--to=pavel@ucw.cz \
--cc=backports@vger.kernel.org \
--cc=julia.lawall@lip6.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=richard.weinberger@gmail.com \
--cc=tytso@mit.edu \
--cc=weigelt@melag.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.