From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4381 Path: news.gmane.org!not-for-mail From: Raphael Cohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files Date: Fri, 6 Dec 2013 11:38:42 +0000 Message-ID: References: <529588D8.3020006@skarnet.org> <20131127184307.GN1685@port70.net> <52965735.9070409@skarnet.org> <529FD33A.8000509@skarnet.org> <20131205144311.GG24286@brightrain.aerifal.cx> <52A0AA6A.60608@skarnet.org> <20131205164022.GK24286@brightrain.aerifal.cx> <52A11C0D.1080705@skarnet.org> <20131206004535.GT24286@brightrain.aerifal.cx> <52A12548.80508@skarnet.org> <20131206053146.GC1685@port70.net> <52A1AB77.3060100@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e015383e48d573404ecdc1649 X-Trace: ger.gmane.org 1386329932 7867 80.91.229.3 (6 Dec 2013 11:38:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Dec 2013 11:38:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4385-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 06 12:38:58 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VotkG-0000Nl-63 for gllmg-musl@plane.gmane.org; Fri, 06 Dec 2013 12:38:56 +0100 Original-Received: (qmail 21646 invoked by uid 550); 6 Dec 2013 11:38:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21632 invoked from network); 6 Dec 2013 11:38:54 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=arTLdsez7sezdbXDaH1QSbVZtVyBeyN7DxEOK4WA958=; b=Z73/abkpschcHHG4QBEorAqeoenha3vUIWCm/wXYMyYlS0yQqGnwKIcrfJK8QuyKfO JOAfjlGsjdNnBuJpp/0vmXHMqvp2hZBXT3NrXewhNh64yF6t48SXv/SxwEdfOojJByLV wVwPNsd2RufXJmjbBdCJQ2kiNNVcsg57M02HuuGc0eDWuY6mEcSKawcMHRVdfcgt/4Zp 05pscrSoUdGXZpXHdRD9QftcAUjGWEZay0Jo9PrHj5KqLONRUzemOtwbazLBEFaNg6TN KbqIiWqy2mMOZFTC0rxPfQDaqWWytV4MfCX4kVFee7yLijZ3IOw+ZdRZUu56rB4fMdZL XEyg== X-Gm-Message-State: ALoCoQmwAM8a4z25sB93XJhKuZqnNvYxZxtzkBWqYCf1qCIlBpI7Y/DHEeV3J0eQnJ8Jo7OhUr8w X-Received: by 10.182.196.3 with SMTP id ii3mr2139287obc.11.1386329922158; Fri, 06 Dec 2013 03:38:42 -0800 (PST) X-Originating-IP: [2001:8b0:862:b944:1917:e668:7ba:525e] In-Reply-To: <52A1AB77.3060100@skarnet.org> Xref: news.gmane.org gmane.linux.lib.musl.general:4381 Archived-At: --089e015383e48d573404ecdc1649 Content-Type: text/plain; charset=UTF-8 I'm not sure I've completely followed all the ramifications here. Why should one have to restart processes on 1,000s of nodes for something like this? 5 9s contracts are hard enough to satisfy at the best of times, without adding another 30 - 120 seconds of restart impact, degraded performance and failover for large jobs. In the sorts of sites we operate in, there might be just one admin for the entire estate, and they're busy enough, and probably laden down with more special knowledge than they can recall as it is, to have to deal with something like this as well... >From this point of view, a system update of packages and data files should be accommodated automatically. Isn't that what a file watch is for? Actually, I'd argue the same for any change to any file of configuration data used by a library. There's no way an userspace app is going to know with certainty what files its underlying linked libs are using or how. That said, I'm all for getting this right - but I'll leave it to others what that means, with one caveat. Date and time match has been got wrong in every system (eg a swap pricing engine, a national telco ordering system) and programming language I've used where it actually mattered... Java are on their third cut at it, for starters... Personally, I think apps should just use a monotonic source of seconds from an epoch, and use a well-developed third party lib dedicated to the problem if they need date math (eg Joda time in Java). On 6 December 2013 10:48, Laurent Bercot wrote: > > - musl should not have configuration options that change >> the behaviour of an api (otherwise maintaining the code >> becomes much harder) so making leapseconds a libc build >> time config option does not work >> > > Also, that would break musl's policy of "compile once, run > everywhere". Leap second usage should be a system-wide setting, > not a binary-wide setting. > > > > - hardcoding leapsecond tables into libc does not work either >> requires recompilations and restarts >> > > Of course. Leap second tables should be read either from the > timezone files, as glibc does, or from a separate file. > > > > - if the clock source is a kernel level setting then the >> information should come from the kernel (eg in the aux >> vector or /proc) >> - if the clock source setting is an external setting (eg the >> configured time server uses GPS or TAI time scale) then the >> admin should provide the information through the filesystem, >> > > musl shouldn't try to autodetect settings from the kernel. The > admin should be the authoritative source of information. > > > > but an update is still an operational hazard, and we need >> to invent a file format and provide tools to get it from the >> distributed tzdata files >> > > That's the easy part. I'm already doing that for skalibs. I'm > willing to provide the format and the tools. > > > > - during the life-time of a process adding leapseconds may >> cause problems so the data should be cached at startup or >> on demand at the first gmtime call, but then there might be >> problems across processes if they don't have the same cached >> leapsecond list >> > > Again, leap second announcements are a rare event and there's > plenty of time for admins to restart their processes. I don't > think that's something musl should care about. > > -- > Laurent > > --089e015383e48d573404ecdc1649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure I've completely followed all the rami= fications here. Why should one have to restart processes on 1,000s of nodes= for something like this? 5 9s contracts are hard enough to satisfy at the = best of times, without adding another 30 - 120 seconds of restart impact, d= egraded performance and failover for large jobs. In the sorts of sites we o= perate in, there might be just one admin for the entire estate, and they= 9;re busy enough, and probably laden down with more special knowledge than = they can recall as it is, to have to deal with something like this as well.= ..

From this p= oint of view, a system update of packages and data files should be accommod= ated automatically. Isn't that what a file watch is for? Actually, I= 9;d argue the same for any change to any file of configuration data used by= a library. There's no way an userspace app is going to know with certa= inty what files its underlying linked libs are using or how.

That said, I'm all for getting thi= s right - but I'll leave it to others what that means, with one caveat.= Date and time match has been got wrong in every system (eg a swap pricing = engine, a national telco ordering system) and programming language I've= used where it actually mattered... Java are on their third cut at it, for = starters... Personally, I think apps should just use a monotonic source of = seconds from an epoch, and use a well-developed third party lib dedicated t= o the problem if they need date math (eg Joda time in Java).


<= div class=3D"gmail_quote">On 6 December 2013 10:48, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:

- musl should not have configuration options that change
=C2=A0 =C2=A0the behaviour of an api (otherwise maintaining the code
=C2=A0 =C2=A0becomes much harder) so making leapseconds a libc build
=C2=A0 =C2=A0time config option does not work

=C2=A0Also, that would break musl's policy of "compile once, run everywhere". Leap second usage should be a system-wide setting,
not a binary-wide setting.



- hardcoding leapsecond tables into libc does not work either
=C2=A0 =C2=A0requires recompilations and restarts

=C2=A0Of course. Leap second tables should be read either from the
timezone files, as glibc does, or from a separate file.


- if the clock source is a kernel level setting then the
=C2=A0 =C2=A0information should come from the kernel (eg in the aux
=C2=A0 =C2=A0vector or /proc)
- if the clock source setting is an external setting (eg the
=C2=A0 =C2=A0configured time server uses GPS or TAI time scale) then the =C2=A0 =C2=A0admin should provide the information through the filesystem,

=C2=A0musl shouldn't try to autodetect settings from the kernel. The admin should be the authoritative source of information.
<= br>

=C2=A0 =C2=A0but an update is still an operational hazard, and we need
=C2=A0 =C2=A0to invent a file format and provide tools to get it from the =C2=A0 =C2=A0distributed tzdata files

=C2=A0That's the easy part. I'm already doing that for skalibs. I&#= 39;m
willing to provide the format and the tools.



- during the life-time of a process adding leapseconds may
=C2=A0 =C2=A0cause problems so the data should be cached at startup or
=C2=A0 =C2=A0on demand at the first gmtime call, but then there might be =C2=A0 =C2=A0problems across processes if they don't have the same cach= ed
=C2=A0 =C2=A0leapsecond list

=C2=A0Again, leap second announcements are a rare event and there's
plenty of time for admins to restart their processes. I don't
think that's something musl should care about.

--
=C2=A0Laurent


--089e015383e48d573404ecdc1649--