Hi Ross,
What I am more after is trying to convince upstream systemd that this might be
a potential problem within the embedded world.
Considering that date might get set by a malicious ntp server. In that case
user space stops booting for us and I guess my understanding is same thing will
hap
> On Sep 8, 2015, at 5:18 AM, Phil Blundell wrote:
>
> On Tue, 2015-09-08 at 13:44 +0200, Umut Tezduyar Lindskog wrote:
>> Can 32 bits ISA handle year 2038 problem in openembedded?
>
> Not generically. But this is not an OE-level problem; the issue is more
> that the underlying libraries and k
On Tue, 2015-09-08 at 13:44 +0200, Umut Tezduyar Lindskog wrote:
> Can 32 bits ISA handle year 2038 problem in openembedded?
Not generically. But this is not an OE-level problem; the issue is more
that the underlying libraries and kernel ABIs are not currently
Y2038-safe. Fixing this is not real
On 8 September 2015 at 12:44, Umut Tezduyar Lindskog wrote:
> Upstream systemd’s answer is pretty much using 64 bits time_t structure
> but this is relatively expensive on 32 bits ISA.
>
What problem are you trying to solve here - the general problem of "I want
my hardware to work after 2038" or
Hi,
Can 32 bits ISA handle year 2038 problem in openembedded?
Our ISA is 32 bits and we are using relatively new kernel with relatively old
glibc (2.15). We are using RTC chips which come with a random date/time
initialized. We started seeing boot problems in systemd if the random value of
RTC
