On 22/02/2016 at 11:41:01 -0500, Austin S. Hemmelgarn wrote :
> On 2016-02-22 11:18, Arnd Bergmann wrote:
> >On Monday 22 February 2016 16:56:53 Alexandre Belloni wrote:
> >>One other workaround is to asked distributions
> >>using systemd to stop using HCTOSYS so userspace would be responsible to
>
On 2016-02-22 11:18, Arnd Bergmann wrote:
On Monday 22 February 2016 16:56:53 Alexandre Belloni wrote:
One other workaround is to asked distributions
using systemd to stop using HCTOSYS so userspace would be responsible to
set the system time and in that case we won't have the 32/64 discrepancy.
On 22/02/2016 at 17:18:03 +0100, Arnd Bergmann wrote :
> > > IIRC, the problem is that user space passes in TIME_T_MAX and the kernel
> > > is considering that to be in the past because the clock is set beyond
> > > 2038.
> > >
> > > I find it hard to blame user space for that, but I don't have a
On Monday 22 February 2016 16:56:53 Alexandre Belloni wrote:
> On 22/02/2016 at 16:44:32 +0100, Arnd Bergmann wrote :
> > On Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote:
> > > On Mon, 22 Feb 2016 14:00:14 +0100
> > > Alexandre Belloni wrote:
> > > > I can also agree that systemd cou
On 22/02/2016 at 16:44:32 +0100, Arnd Bergmann wrote :
> On Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote:
> > On Mon, 22 Feb 2016 14:00:14 +0100
> > Alexandre Belloni wrote:
> > > I can also agree that systemd could be a bit more robust there but
> > > you'll have to convince Lennart
On Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote:
> On Mon, 22 Feb 2016 14:00:14 +0100
> Alexandre Belloni wrote:
> > I can also agree that systemd could be a bit more robust there but
> > you'll have to convince Lennart...
>
> That's a systemd problem. If their code isn't robust the
On Mon, 22 Feb 2016 14:00:14 +0100
Alexandre Belloni wrote:
.
> But there are long lived products like cars, parking ticket machines,
> insulin pumps, automated external defibrillators, home automation
> controllers, point of sales, etc... Some of those may still be in use in
> 22 years.
And if s
On 21/02/2016 at 12:40:20 +, One Thousand Gnomes wrote :
> > It doesn't change anything for 64-bit systems, I've excluded them by
> > using "depends on !64BIT". Right now, it doesn't change anything for
> > 32-bit systems because either way, they will fail in 2038.
>
> Which realistically won'
> It doesn't change anything for 64-bit systems, I've excluded them by
> using "depends on !64BIT". Right now, it doesn't change anything for
> 32-bit systems because either way, they will fail in 2038.
Which realistically won't actually matter because in 22 years time nobody
will be able to find
On 21/02/2016 at 00:17:02 +0100, Alexandre Belloni wrote :
> All the failures seem quite random to me but the reports I get are not
> that precise.
>
> I know it happens with PCF8523 and that can be true because the
> datasheet says the date is undefined at reset. The handling of the OS
> bit (tha
On 20/02/2016 at 23:16:48 +0100, Arnd Bergmann wrote :
> On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> >
> > Actually, I'm not trying to solve the 2038 issue.
> >
> > But in the current state on 32 bit platforms, while the kernel is able
> > to handle a 64bit date, userspace is
On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
>
> Actually, I'm not trying to solve the 2038 issue.
>
> But in the current state on 32 bit platforms, while the kernel is able
> to handle a 64bit date, userspace is not. The main issue is that
> distributions use HCTOSYS so if the
On 20/02/2016 at 19:43:10 +, One Thousand Gnomes wrote :
> On Sat, 20 Feb 2016 20:10:44 +0100
> Alexandre Belloni wrote:
>
> > hctosys is setting the system time from the kernel. This means that 32bit
> > system can get their time set to a date after the 31bit time_t overflow.
> >
> > This i
On Sat, 20 Feb 2016 20:10:44 +0100
Alexandre Belloni wrote:
> hctosys is setting the system time from the kernel. This means that 32bit
> system can get their time set to a date after the 31bit time_t overflow.
>
> This is currently an issue as userspace is not yet ready to handle those
> dates
hctosys is setting the system time from the kernel. This means that 32bit
system can get their time set to a date after the 31bit time_t overflow.
This is currently an issue as userspace is not yet ready to handle those
dates and may break. For example systemd's usage of timerfd shows that the
tim
15 matches
Mail list logo
