linux-kernel - Re: Future of the -longterm kernel releases (i.e. how we pick them).

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Aug 2011 21:49:22 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Greg KH <greg@...ah.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Tim Bird <tbird20d@...il.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, stable-review@...nel.org,
	stable@...nel.org, tim.bird@...sony.com,
	Arve Hjønnevå <arve@...roid.com>
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick them).

On Tue, Aug 23, 2011 at 9:57 PM, Greg KH <greg@...ah.com> wrote:
> On Wed, Aug 17, 2011 at 10:33:05AM -0700, Brian Swetland wrote:
>> As far as long-term kernels goes, from the Android perspective we
>> strongly prefer to snap up to the most recent released kernel on every
>> platform/device release.  I prefer to be as up to date on bugfixes and
>> features from mainline as possible and minimize the deltas on our
>> stack 'o patches as much as possible.
>
> That's good to hear.
>
>> We've been getting more aggressive about merging in the -rc#s and then
>> rebasing on the final during development (before final stabilization
>> freeze for a release) in the last year or so, and it seems to work
>> pretty well.
>
> Is your kernel git tree public during this merge cycle so that others
> can track it?  I tried to dig through android.kernel.org but there are a
> lot of different kernel trees there :(

We really need a "which branch is which" quick guide that's easily
findable.  kernel/common is always where our generic patch stack
lives, and it looks like android-3.0 is the most recent (which has
3.0.1 merged in).

http://android.git.kernel.org/?p=kernel/common.git;a=summary

>> Not all OEMs or silicon vendors are as comfortable with this approach
>> and I expect some would welcome a long term tree they can count on to
>> get critical fixes for, though.  Device release teams (even our own,
>> for lead devices we work on) are notoriously risk-averse (often for
>> good reasons), and tend to get really nervous when they see the total
>> change count or diff stat for pulling up to a new kernel release close
>> to "final rom" for a product.
>
> That's understandable.
>
> So that kind of means they would like such a longterm tree, but they
> have the problem that your patches move forward to a newer kernel, but
> are not maintained for that longterm kernel.  Are they responsible for
> maintaining this themselves then, or do you help with providing your
> patchset on top of all of the different kernel versions that the OEMs
> and others need?

So far the silicon vendors have been doing more of the longer term
kernel stuff, as it better matches their model of providing "boxed"
stable BSPs of some sort.  It might make sense for us to ensure
backports of fixes for core patches (our common tree) are available
for the LT kernels, but we are unlikely to have the necessary staff to
maintain LT trees for every SoC we interact with.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/