On Fri, Oct 07, 2016 at 06:47:47AM -0700, Thomas Hellstrom wrote:
> Given a *binary* version of distro kernel X, based on stable kernel Y.
> What _upstreamed_ bugfix patches has touched our module since the stable
> branch was created? Let's assume the distro git tree is hard to find.
>
> a) Now if stable maintainers and distro kernel maintainers could use a
> flag "record commit id" to the git am command, the mainline commit id
> would be added to a binary visible table in the module, problem solved.
^^^^^^^^^^^^^^
Are you kidding ? For this you'd have :
1) to patch each stable kernel to include such a list of commit IDs
2) to include the whole list of upstream commit IDs into each module
since you never know what commit affects what. For example, good
luck for guessing what module is affected by this patch merged in
4.4.24 :
commit 70cd763eb1574cac07138be91f474a661e02d694
Author: Subash Abhinov Kasiviswanathan <subashab@xxxxxxxxxxxxxx>
Date: Thu Aug 25 15:16:51 2016 -0700
sysctl: handle error writing UINT_MAX to u32 fields
commit e7d316a02f683864a12389f8808570e37fb90aa3 upstream.
We have scripts which write to certain fields on 3.18 kernels but this
seems to be failing on 4.4 kernels. An entry which we write to here is
xfrm_aevent_rseqth which is u32.
echo 4294967295 > /proc/sys/net/core/xfrm_aevent_rseqth
(...)
3) to needless inflate the kernels and initrd people are using
4) to add more burden on the shoulders of the people already doing the
job the most transparent manner possible, and who are already
asking several times a week for upstream IDs when someone asks for
a patch to be backported.
All this to *hope* to get these IDs from your theorically opensourced
kernels which you hope to know the base version. So if a kernel is called
3.10.73.46-g12345 it is supposed to contain all of 3.10.73 plus some changes
local to your vendor. It means the vendor will backport such changes
themselves, and you can be certain that they won't spend their time going
through the extra pain you're asking for if they already don't take the
time to *at least* rebase on the latest stable release of the same branch.
In all cases you're supposed to have their sources. Even if you only have
a huge tarball, you can diff it against the mainline kernels (I do that
from time to time when I want to rebase a shitty vendor BSP on top of
latest stable), so you can actually always figure what was merged and
what not.
If you don't get enough transparency from your vendor and this causes you
such a burden to track changes, you should simply let your vendor know.
Willy
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html