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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 23 Aug 2011 21:57:02 -0700
From:	Greg KH <greg@...ah.com>
To:	Brian Swetland <swetland@...gle.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 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 :(

> 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?

thanks,

greg k-h
--
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/