Re: Stable list vs versioning

[Willy Tarreau <w@1wt.eu>]

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@codeaurora.org>
     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