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 wrot
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 (a...@arndb.de
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 ar
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, 14.08.
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 t
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, f
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 h
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 setting
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 RTC
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 ker
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 lot
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 "pe
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 ker
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 t
* 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 suchlike
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 sense.
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) Do
25 matches
Mail list logo