On 27/08/2019 18:27:32+0200, Arnd Bergmann wrote:
> On Tue, Aug 20, 2019 at 8:58 PM Alexandre Belloni
> wrote:
> >
> > On 19/08/2019 13:09:03+0200, Karel Zak wrote:
> > > On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > > > On 14/08/2019 11:09:36+0200, Lennart Poettering
On Tue, Aug 20, 2019 at 8:58 PM Alexandre Belloni
wrote:
>
> On 19/08/2019 13:09:03+0200, Karel Zak wrote:
> > On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > > On Mi, 14.08.19 10:31, Arnd Bergmann
On 19/08/2019 13:09:03+0200, Karel Zak wrote:
> On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> > >
> > > > - glibc stops passing the caller timezone
On 19/08/2019 15:43:03+0200, Thomas Gleixner wrote:
> On Mon, 19 Aug 2019, Karel Zak wrote:
> > On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> > >
On 19/08/2019 15:49:24+0200, Thomas Gleixner wrote:
> On Mon, 19 Aug 2019, Thomas Gleixner wrote:
> > On Mon, 19 Aug 2019, Karel Zak wrote:
> > > On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > > > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > > > On Mi,
On Mon, 19 Aug 2019, Thomas Gleixner wrote:
> On Mon, 19 Aug 2019, Karel Zak wrote:
> > On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> > > >
> > >
On Mon, 19 Aug 2019, Karel Zak wrote:
> On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> > On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> > >
> > > > - glibc stops passing the caller timezone argument
On Wed, Aug 14, 2019 at 11:32:08AM +0200, Alexandre Belloni wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> >
> > > - glibc stops passing the caller timezone argument to the kernel
> > > - the distro kernel disables
On August 15, 2019 8:05:30 AM PDT, "Theodore Y. Ts'o" wrote:
>On Thu, Aug 15, 2019 at 03:22:45PM +0200, Arnd Bergmann wrote:
>> If 64-bit Windows relies on a working EFI RTC implementation, we
>could
>> decide to leave the driver enabled on 64-bit and only disable it for
>> 32-bit EFI. That way,
On Thu, Aug 15, 2019 at 03:22:45PM +0200, Arnd Bergmann wrote:
> If 64-bit Windows relies on a working EFI RTC implementation, we could
> decide to leave the driver enabled on 64-bit and only disable it for
> 32-bit EFI. That way, future distros would no longer have to worry about
> the localtime
On Wed, Aug 14, 2019 at 6:48 PM wrote:
>
> I believe Windows 10 changed the default RTC to UTC, although perhaps
> only if running under UEFI.
I looked at the efi rtc driver now, and found two things:
- The EFI get_time() call passes down timezone information, so we know what
UTC is, and can
On August 14, 2019 9:26:36 AM PDT, David Laight wrote:
>From: Theodore Y. Ts'o
>> Sent: 14 August 2019 01:06
>> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
>> >
>> > I suspect the only actual _valid_ use in the kernel for a time zone
>> > setting is likely for RTC clock
From: Theodore Y. Ts'o
> Sent: 14 August 2019 01:06
> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
> >
> > I suspect the only actual _valid_ use in the kernel for a time zone
> > setting is likely for RTC clock setting, but even that isn't really
> > "global", as much as "per
On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.bell...@bootlin.com) wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> >
> > > - glibc stops passing the caller timezone argument to the kernel
> > > - the distro
On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
>
> > - glibc stops passing the caller timezone argument to the kernel
> > - the distro kernel disables CONFIG_RTC_HCTOSYS,
> > CONFIG_RTC_SYSTOHC and CONFIG_GENERIC_CMOS_UPDATE
On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> - glibc stops passing the caller timezone argument to the kernel
> - the distro kernel disables CONFIG_RTC_HCTOSYS,
> CONFIG_RTC_SYSTOHC and CONFIG_GENERIC_CMOS_UPDATE
What's the benefit of letting userspace do this? It sounds a
On Wed, Aug 14, 2019 at 2:06 AM Theodore Y. Ts'o wrote:
> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
> >
> > I suspect the only actual _valid_ use in the kernel for a time zone
> > setting is likely for RTC clock setting, but even that isn't really
> > "global", as much as
On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
>
> I suspect the only actual _valid_ use in the kernel for a time zone
> setting is likely for RTC clock setting, but even that isn't really
> "global", as much as "per RTC".
As I recall (and I may or may not have been original for
On 13/08/2019 10:30:34-0700, Linus Torvalds wrote:
> On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann wrote:
> >
> > * Should we allow setting the sys_tz on new architectures that use only
> > time64 interfaces at all, or should we try to get away from that anyway?
>
> We should not do TZ on a
On 13/08/2019 10:10:53-0700, John Stultz wrote:
> On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann wrote:
> > Now, to the actual questions:
> >
> > * Should we allow setting the sys_tz on new architectures that use only
> > time64 interfaces at all, or should we try to get away from that anyway?
>
On Tue, Aug 13, 2019 at 9:31 PM Florian Weimer wrote:
> * Paul Eggert:
> > Linus Torvalds wrote:
> >> I assume/think that glibc uses (a) environment
> >> variables and (b) a filesystem-set default (per-user file with a
> >> system-wide default? I don't know what people do).
>
> > glibc relies on
* Paul Eggert:
> Linus Torvalds wrote:
>> I assume/think that glibc uses (a) environment
>> variables and (b) a filesystem-set default (per-user file with a
>> system-wide default? I don't know what people do).
> glibc relies on the TZ environment variable, with a system-wide
> default specified
Linus Torvalds wrote:
I assume/think that glibc uses (a) environment
variables and (b) a filesystem-set default (per-user file with a
system-wide default? I don't know what people do).
glibc relies on the TZ environment variable, with a system-wide default
specified in /etc/localtime or
On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann wrote:
>
> * Should we allow setting the sys_tz on new architectures that use only
> time64 interfaces at all, or should we try to get away from that anyway?
We should not do TZ on a kernel level at all. At least not a global
one. It makes no
On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann wrote:
> Now, to the actual questions:
>
> * Should we allow setting the sys_tz on new architectures that use only
> time64 interfaces at all, or should we try to get away from that anyway?
So I'd probably cut this question a bit differently:
1)
The riscv32 kernel port uses the new time64 syscall interface that has no
'settimeofday', only 'clock_settime64'. During the review of the glibc port,
the question arose how to deal with the (old, horrible, deprecated) timezone
portion of the settimeofday() libc API.
Typical uses of timezones in
26 matches
Mail list logo