Date: Sat, 17 Mar 2018 07:30:43 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> Cc: Alan Somers <asomers@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, bde@freebsd.org Subject: Re: Is it time to expose timespecsub and friends to userland? Message-ID: <20180317070040.X23799@besplex.bde.org> In-Reply-To: <1521228930.99081.66.camel@freebsd.org> References: <CAOtMX2h03kM36ocyPut__yf-S0Ry2_sOkQCHeFb1GZ4K8NM1Fg@mail.gmail.com> <1521223787.99081.63.camel@freebsd.org> <65723.1521226854@critter.freebsd.dk> <CAOtMX2izMeWGAh4t0zVb92NuHj-4cFpRsBTy-jUsGGhR4yyCTQ@mail.gmail.com> <1521228930.99081.66.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Mar 2018, Ian Lepore wrote: > On Fri, 2018-03-16 at 13:31 -0600, Alan Somers wrote: >> On Fri, Mar 16, 2018 at 1:00 PM, Poul-Henning Kamp >> <phk@phk.freebsd.dk> wrote: >> >>> >>> -------- >>> In message <1521223787.99081.63.camel@freebsd.org>, Ian Lepore >>> writes: >>> >>>> >>>> IMO, it's long overdue.=A0=A0I've never understood why they weren't >>>> exposed >>>> on the day the were added. >>> I have a faint recollection that there were many copies in >>> userland already which I didn't want to deal with right there and >>> then. >>> =A0[...] >>> >> Good point.=A0=A0A quick grep finds a few examples.=A0=A0I'll make sure = to >> remove >> them. > > Hmm, I'll bet there are some ports that also define the obvious names > locally and that'll cause problems if we move the names out from under > #ifdef __KERNEL. =A0So an exp-run will probably be needed too. The bug of these APIs existing is only clearly in NetBSD, OpenBSD and Oracle. For Linux and glibc, google reports that as late as 2011, users are confused by timersub() not existing except possibly under a BSDSRC ifdef. FreeBSD should continue to avoid this bug for timespec*(). FreeBSD's timespec*(9) APIs are fully incompatible with NetBSD, OpenBSD and Oracle timespec*(3) APIs. The latter have 3 args with the target last, like the timeval*(3) APIs, but timespec*(9) still has 2 args with the target first. The incompability might be intentional, to keep the APIs out of userland, but more likely it is just to have the same number of args and order as the old timeval*(9) APIs. These are better designed than timer*(), except they take only 2 args. Their args are in the correct order, with the target first, and their name is not too generic. timespec*(9) copies these APIs except for s/timeval/timespec/. NetBSD's timer*(3) might have a different though worse name to since their different args make them very different. This difference would reduce conflicts with application APIs. However, for timespec*(), using the same name increases conflicts with application APIs. The special reserved symbols in sys/time.h in old versions of POSIX were just ones with prefix tv_, it_ and a few more from sys/select.h. Not timespec* or timeval*. So it is very reasonable for applications to name their own APIs timespec*. Using the system's pollution is just harder -- it needs autoconfig or something to use it when it exists, and possibly macros to convert between 2-arg and 3-arg forms, and also private APIs to use when the system headers are not polluted. Bruce From owner-freebsd-hackers@freebsd.org Sat Mar 17 17:46:23 2018 Return-Path: <owner-freebsd-hackers@freebsd.org> Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE97F5BE6A for <freebsd-hackers@mailman.ysv.freebsd.org>; Sat, 17 Mar 2018 17:46:22 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 717CE8677C; Sat, 17 Mar 2018 17:46:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w2HHcFTI052028 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Mar 2018 10:38:15 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w2HHcF96052027; Sat, 17 Mar 2018 10:38:15 -0700 (PDT) (envelope-from jmg) Date: Sat, 17 Mar 2018 10:38:15 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Eitan Adler <lists@eitanadler.com> Cc: John Baldwin <jhb@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: gf128_add can be marked as __pure2 Message-ID: <20180317173815.GM75576@funkthat.com> Mail-Followup-To: Eitan Adler <lists@eitanadler.com>, John Baldwin <jhb@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> References: <CAF6rxgn7eEu5WZBH93N4AMHcwCwU3cdhH3rhQunTY+Co4PvX4w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAF6rxgn7eEu5WZBH93N4AMHcwCwU3cdhH3rhQunTY+Co4PvX4w@mail.gmail.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 17 Mar 2018 10:38:16 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 17 Mar 2018 17:46:23 -0000 Eitan Adler wrote this message on Mon, Feb 19, 2018 at 19:15 -0800: > Is there any reason not to apply this patch? I don't see why there wouldn't be.. > __pure2 means __attribute__((const)) which is correct in this case as > gf128_add read no global memory: Are these documented some where? Looksl ike __pure2 was created instead of using __pure for some reason... I wish these things were documented properly so others could know the correct usage... > Index: gfmult.h > =================================================================== > --- gfmult.h (revision 329611) > +++ gfmult.h (working copy) > @@ -108,7 +108,7 @@ gf128_write(struct gf128 v, uint8_t *buf) > be64enc(buf, v.v[1]); > } > > -static inline struct gf128 __pure /* XXX - __pure2 instead */ > +static inline struct gf128 __pure2 > gf128_add(struct gf128 a, struct gf128 b) > { > a.v[0] ^= b.v[0]; -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180317070040.X23799>