Is it time to expose timespecsub and friends to userland?

Bruce Evans brde at optusnet.com.au
Fri Mar 16 21:00:26 UTC 2018


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 at phk.freebsd.dk> wrote:
>>
>>>
>>> --------
>>> In message <1521223787.99081.63.camel at freebsd.org>, Ian Lepore
>>> writes:
>>>
>>>>
>>>> IMO, it's long overdue.  I'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.
>>>  [...]
>>>
>> Good point.  A quick grep finds a few examples.  I'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.  So 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


More information about the freebsd-hackers mailing list