From nobody Sun Jun 02 18:36:38 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vslv86ntpz5JkZs for ; Sun, 02 Jun 2024 18:36:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vslv764wWz4Tt2 for ; Sun, 2 Jun 2024 18:36:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2c19bba897bso2765509a91.2 for ; Sun, 02 Jun 2024 11:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1717353410; x=1717958210; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vnt9Y1PBS3pzvK/jx4g+XoUASUEUlAb8XjWBSUR1bTI=; b=SvD6eFNVjaCIvuQtY248CGwdC7GPVbGf291IYv9saFDAwsyW4Yzq8DYc10DJgBvtSE YyJDMa6xnQklST285bhcvbiz/L3t1kzs1L4XEtVPKahpsij9zrAGRvRQO9fCknJCY34q wiccTcAUBmZgkut6ali1UJnQ6N2xZyTfSJH4j9hoeTS9unoDJzJH6GPHC/WS05ooeVCX 355H/uqRR4E5QT4khgpvxF0UFlb9aTQkm2JVs1bDlm1cv+QMMpr52YopGWf/cHhFZ/Oo TijaezoHbItPwXBGytocjbxQvHElRlONliSYI4T13q9PnkelPynlEmUSn5HLY+SokWyg z15Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717353410; x=1717958210; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vnt9Y1PBS3pzvK/jx4g+XoUASUEUlAb8XjWBSUR1bTI=; b=LPhX32oqFSWu6rTNDpqttr/j+2hf0QCVvQofZxkyVbMQ0oHCPfbFGmayVKjy2xrtmN jftthDHW4C3yH4tEFViGGMTtUFQZ8J2EP61sdHbR8PHF+TaMGJ1a3rUkvBJI4hde09Gx SkXQuUcdbUntfPYdgC3PmltimE6k/fASVNQSdTq/y43JhapqlgyYnYbpVnS/AdprfTrU SMpdlo4Xb9Rqa4YAt1ze6L061oOuIB17BDs9W8IMYZk8isyNGWbvB2QQR41kJC0i5qVD +m39Xrfpvk+gbXDN0yBOSoe+eIA8bAits5mcA9KwfUE/AFrIzWMacjmBXBStURie5yV/ lvxA== X-Forwarded-Encrypted: i=1; AJvYcCX/3NckAU0xMZXUXhn8L2sVd3Xnq5bT5ZbJ2CHeZzcDeNwk1t8EA5Tj7W60a8VM5pEZlIjmzLUXil+SEdsFCLwVQMshirm7qy8olwlEyeEO X-Gm-Message-State: AOJu0YzSonRguG3gN1dq8GB7zpTo2zWiaPbXy9t3edmOn4BIowR/IDhF eEPOcggh4RVi5FvjnNUHtXNvvknzsM1pAMWeraxRD5dXAhVrA+h4GxzdBWOSQAmy6CpuHQB+cpQ MbdV4XX/HRf9gZubiDR+cFGjv+MjVpzq/n3qpMA== X-Google-Smtp-Source: AGHT+IHiB4j7g8h6mvqM7OdjClDPxOuieVJPgY2xyVbalgv92cn+6KJRh6l0r39YqZY8Nv2FQvGnatfjRUGjWoWwJZI= X-Received: by 2002:a17:90b:218c:b0:2b9:78b9:fefe with SMTP id 98e67ed59e1d1-2c1dc5cd72bmr5428129a91.47.1717353409931; Sun, 02 Jun 2024 11:36:49 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202405311447.44VEl1G1078199@gitrepo.freebsd.org> <20240601224055.6a6cac10@slippy> <3049031.hHqAuc6tWs@francois> In-Reply-To: <3049031.hHqAuc6tWs@francois> From: Warner Losh Date: Sun, 2 Jun 2024 14:36:38 -0400 Message-ID: Subject: Re: git: 108de784513d - main - Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME To: Olivier Certner Cc: Warner Losh , Nuno Teixeira , Cy Schubert , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000f405e00619ec7fa2" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Vslv764wWz4Tt2 --000000000000f405e00619ec7fa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 2, 2024 at 2:05=E2=80=AFPM Olivier Certner w= rote: > Hi, > > Some food for thought. > > Given the (minor?) fallout, I wonder if we should have instead just added > a distinct numerical value for CLOCK_BOOTTIME, which didn't occur to me > while doing the review. This would have the benefit of allowing all thes= e > 'case' labels to coexist, which makes the interface more predictable and > thus easier on applications. The patches below obviously only can cover > the precise applications that we noticed failed to compile, and not other > existing ones nor future ones to be written. I don't see any real drawba= ck > for such an approach because, to read clock information, applications > always have to specify the clock ID and, AFAIK, cannot, e.g., request a > list of clocks and times, where we would have to be careful to output the > same time for all the aliased clock IDs. > Maybe in the future. This issue is completely solved the way that it is now and I think this is over-engineering. It *WAS* an alias for CLOCK_UPTIME and now it's an alias for CLOCK_MONOTONIC. When it went in, other minor changes were also needed, as were changes before it went in. Its semantics and values are implementation defined. Linux happened to define it to have a subtly different meaning than their CLOCK_MOTONIC, and when we adopted it, there was a critical detail I misunderstood. There were at least a dozen applications that were ported to FreeBSD that needed to have the #ifdef added in the days before I added the alias, for example. The new value might have averted this breakage, but it might also have introduced subtle breakage where a program thought these were distinct that we're not seeing. It's hard to say if it's a good or bad idea to adopt a value that's unique to avoid one set of breakage, only to maybe introduce other breakage which would be harder to detect (things compile, but they misbehave, vs this solution where compilation may break, but then you know you have the issue).a So if you want to drive it, drive the exp run, etc, knock yourself out. But given the absolutely trivial amount of fallout, I'm on to the hundreds of more important things that are in my backlog. I consider the problem solved, unless there's new information. But maybe I'm still feeling burned out by the 12 months of iteration that it took to fix all the compatibility issues with something as simple as endian.h.... only to discover 30 months later a new, different subtle breakage. Warner > Thanks. > > -- > Olivier Certner > --000000000000f405e00619ec7fa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Maybe in the future. This issue is completely solved the wa= y that it is now and I think this is over-engineering. It *WAS* an alias fo= r CLOCK_UPTIME and now it's an alias for CLOCK_MONOTONIC. When it went = in, other minor changes were also needed, as were changes before it went in= . Its semantics and values are implementation defined. Linux happened to de= fine it to have a subtly different meaning than their CLOCK_MOTONIC, and wh= en we adopted it, there was a critical detail I misunderstood. There were a= t least a dozen applications that were ported to FreeBSD that needed to hav= e the #ifdef added in the days before I added the alias, for example. The n= ew value might have averted this breakage, but it might also have introduce= d subtle breakage where a program thought these were distinct that we'r= e not seeing. It's hard to say if it's a good or bad idea to adopt = a value that's unique to avoid one set of breakage, only to maybe intro= duce other breakage which would be harder to detect (things compile, but th= ey misbehave, vs this solution where compilation may break, but then you kn= ow you have the issue).a


--000000000000f405e00619ec7fa2--