* Re: y2038 backport to v5.4 [not found] ` <CAK8P3a2icd72R+4Z5dLPvGuofsq3VOBYBdCnC4806V5znqrytg@mail.gmail.com> @ 2020-08-17 14:15 ` Roosen Henri 2020-08-17 14:35 ` gregkh 0 siblings, 1 reply; 5+ messages in thread From: Roosen Henri @ 2020-08-17 14:15 UTC (permalink / raw) To: arnd; +Cc: y2038, linux-kernel, gregkh [-- Attachment #1: Type: text/plain, Size: 1825 bytes --] 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=y2038-endgame > > 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? Thanks, Henri [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 3608 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: y2038 backport to v5.4 2020-08-17 14:15 ` y2038 backport to v5.4 Roosen Henri @ 2020-08-17 14:35 ` gregkh 2020-08-17 15:00 ` Roosen Henri 0 siblings, 1 reply; 5+ messages in thread From: gregkh @ 2020-08-17 14:35 UTC (permalink / raw) To: Roosen Henri; +Cc: arnd, y2038, linux-kernel 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=y2038-endgame > > > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: y2038 backport to v5.4 2020-08-17 14:35 ` gregkh @ 2020-08-17 15:00 ` Roosen Henri 2020-08-17 15:15 ` gregkh 0 siblings, 1 reply; 5+ messages in thread From: Roosen Henri @ 2020-08-17 15:00 UTC (permalink / raw) To: gregkh; +Cc: y2038, linux-kernel, arnd [-- Attachment #1: Type: text/plain, Size: 2762 bytes --] On Mon, 2020-08-17 at 16:35 +0200, gregkh@linuxfoundation.org wrote: > 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=y2038-endgame > > > > > > 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 :) I fully understand, thanks for your statement on this. > > 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... Oh I agree on that :) It's just that these are currently customer requirements. But we'll advice them to upgrade to newer kernels and provide up-to-date kernels for them along the away to and beyond y2038. Thanks, Henri > > thanks, > > greg k-h [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 3608 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: y2038 backport to v5.4 2020-08-17 15:00 ` Roosen Henri @ 2020-08-17 15:15 ` gregkh 2020-08-17 15:38 ` Roosen Henri 0 siblings, 1 reply; 5+ messages in thread From: gregkh @ 2020-08-17 15:15 UTC (permalink / raw) To: Roosen Henri; +Cc: y2038, linux-kernel, arnd On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote: > On Mon, 2020-08-17 at 16:35 +0200, gregkh@linuxfoundation.org wrote: > > 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=y2038-endgame > > > > > > > > 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 :) > > I fully understand, thanks for your statement on this. > > > > > 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... > > Oh I agree on that :) It's just that these are currently customer > requirements. Are you sure that customers really understand what they want? Usually they want a well-supported, stable, system. Why do they care about a specific kernel version? That feels odd. Good luck! greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: y2038 backport to v5.4 2020-08-17 15:15 ` gregkh @ 2020-08-17 15:38 ` Roosen Henri 0 siblings, 0 replies; 5+ messages in thread From: Roosen Henri @ 2020-08-17 15:38 UTC (permalink / raw) To: gregkh; +Cc: y2038, linux-kernel, arnd [-- Attachment #1: Type: text/plain, Size: 3609 bytes --] On Mon, 2020-08-17 at 17:15 +0200, gregkh@linuxfoundation.org wrote: > On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote: > > On Mon, 2020-08-17 at 16:35 +0200, gregkh@linuxfoundation.org > > wrote: > > > 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=y2038-endgame > > > > > > > > > > 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 :) > > > > I fully understand, thanks for your statement on this. > > > > > 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... > > > > Oh I agree on that :) It's just that these are currently customer > > requirements. > > Are you sure that customers really understand what they want? > > Usually they want a well-supported, stable, system. Why do they care > about a specific kernel version? That feels odd. I think the industry is learning that almost no systems can be left untouched and a well-supported, upgradeable system is needed. That has always been our vision and we're providing that for them. Thanks, Henri > > Good luck! > > greg k-h [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 3608 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-08-17 15:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <d159c66c6e67480ab48ac44716443358@ginzinger.com> [not found] ` <CAK8P3a2icd72R+4Z5dLPvGuofsq3VOBYBdCnC4806V5znqrytg@mail.gmail.com> 2020-08-17 14:15 ` y2038 backport to v5.4 Roosen Henri 2020-08-17 14:35 ` gregkh 2020-08-17 15:00 ` Roosen Henri 2020-08-17 15:15 ` gregkh 2020-08-17 15:38 ` Roosen Henri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).