On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri < Henri.Roosen@ginzinger.com> wrote:
Hi Arnd,
I hope you are well and could answer me a quick question.
I've read on the kernel mailing-list that initially there was an intention to backport the final y2038 patches to v5.4. We're currently targeting to use the v5.4 LTS kernel for a project which should be y2038 compliant.
I couldn't find all of the y2038-endgame patches in the current v5.4-stable branch. Are there any patches still required to be backported in order for v5.4 to be y2038 compliant, or can the remaining patches be ignored (because of only cleanup?)? Else, is there still an intention to get the v5.4 LTS kernel y2038 compliant?
I don't think there are currently any plans to merge my y2038-endgame branch into the official linux-5.4 lts kernel, but you should be able to just pull from
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y...
and get the same results. If you see any problems with that, please report that to me with Cc to the mailing list and perhaps gregkh, so I can see if I can resolve it by rebasing my patches, or if he would like to merge the patches.
Pulling the y2038-endgame branch does lead to some conflicts, which are currently still kinda staightforward to solve.
However I'd be very interested in getting this branch merged to v5.4, so we don't run into more difficult merge conflicts the coming years where the v5.4-LTS still gets stable updates (Dec, 2025) and possibly to get any related fixes from upstream.
@Greg: any chance to get the y2038-endgame merged into v5.4.y?
I have no idea what this really means, and what it entails, but odds are, no :)
Why not just use a newer kernel? Why are you stuck using a 5.4 kernel for a device that has to live in 2038? That feels very foolish to me...
thanks,
greg k-h