Re: y2038 backport to v5.4

Re: y2038 backport to v5.4

[Roosen Henri]

[-- 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 --]

Re: y2038 backport to v5.4

[gregkh]

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

Re: y2038 backport to v5.4

[Roosen Henri]

[-- 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 --]

Re: y2038 backport to v5.4

[gregkh]

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

Re: y2038 backport to v5.4

[Roosen Henri]

[-- 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 --]