Date: Tue, 20 Jan 2004 22:32:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: itojun@iijlab.net Cc: rrs@cisco.com Subject: Re: timersub/timeradd/timercmp Message-ID: <20040120210418.V3916@gamplex.bde.org> In-Reply-To: <20040120063133.EC399B2@coconut.itojun.org> References: <20040120063133.EC399B2@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jan 2004 itojun@iijlab.net wrote: > could anyone let me know why timersub/add/cmp are disabled in the > kernel? They are spelled timevalsub/add/cmp in the kernel. This is a better spelling, since there are several data structures that can represent the time. timersub/add/cmp are disabled in the kernel to prevent regressions to worse names. > they were introduced in 4.4BSD, Actually, they were mostly introduced in NetBSD. 4.4BSD only has timercmp (and some other timer* functions) as a macro, and timevalsub/add as (unprototyped, not even declared) non-inline functions. FreeBSD picked up timersub/add from NetBSD for use in userland, and soon after renamed timercmp to timevalcmp in the kernel, and added timeval* for userland and timespec* for the kernel, and a few years later added bintime* for both the userland and the kernel. So FreeBSD now has kitchensinktime*^Wtimekitchensink*, and is only missing timercmp in the kernel relative to 4.4BSD. > and (non-)availability of > these macro makes it difficult for kame/rrs to deal with multiple > *BSDs. (guessing: are you trying to enforce the use of timespec > in the kernel?) That may have been a minor reason (before FreeBSD renamed timercmp to get the consistently better timeval* names). I tried to prevent timersub/add from being exported to userland. timevals are stupid interfaces that were needed when CPUs were slow and couldn't do floating point or wide integer operations very well. Why introduce macros to operate on them several years after they became obsolete? Portable code can't use these macros anyway. I agree the timeval access macros are better suited to things like adjusting select() timeouts than converting everything to floating point and back. It was in Dec. 1996 that timevals had been obsolete for several years and FreeBSD picked up the timer macros from NetBSD. timevals weren't obsolete in practice then of course. timespecs had only been standard in POSIX for 8 years, and lots of interfaces still used only timevals. 7 years later, time handling is messier than ever. POSIX has standardized all the old interfaces, so timevals are unlikely to go away for more than another 8+7 years (I guess twice that). OTOH, timespecs stopped being precise enough for some applications at about the same time as POSIX regressed from supporting only timespecs. phk is now trying to convert things to bintimes, and C99 couldn't agree on any useful extensions of time_t. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040120210418.V3916>