From owner-cvs-sys  Mon Dec 30 18:12:42 1996
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id SAA06549
          for cvs-sys-outgoing; Mon, 30 Dec 1996 18:12:42 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA06538;
          Mon, 30 Dec 1996 18:12:19 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id KAA02604;
          Tue, 31 Dec 1996 10:11:58 +0800 (WST)
Message-Id: <199612310211.KAA02604@spinner.DIALix.COM>
X-Mailer: exmh version 1.6.9 8/22/96
To: Bruce Evans <bde@zeta.org.au>
cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, peter@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/sys time.h 
In-reply-to: Your message of "Tue, 31 Dec 1996 11:10:51 +1100."
             <199612310010.LAA14486@godzilla.zeta.org.au> 
Date: Tue, 31 Dec 1996 10:11:58 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Bruce Evans wrote:
> >  Modified:    sys/sys   time.h
> >  Log:
> >  Add NetBSD/OpenBSD compatable timeradd()/timersub() user-space macros.
> >  
> >  These are deliberately not visible to the kernel since we have timevaladd(
    )
> >  and timevalsub() functions there.
> >  
> >  Obtained from: NetBSD/OpenBSD
> 
> Arrghh.  I've already explained at length why we don't need these.
> NetBSD needs them for the kernel because they turned the functions into
> macros.  This was probably a mistake because the functions are too large
> to be macros on many machines; in any case, they are not in an inner
> loop.  Making them visible outside the kernel is more obviously wrong.
> It breaks any applications that have private versions of them with the
> same name, and timevals are a stupid format to use outside the kernel.
> The kernel uses them mainly because long longs and efficient floating
> point operations weren't available 10 years ago.  Why add support for
> a bad method 5-10 years after it became bad?

Because they are frozen into interfaces like select() and the rpc API.  
Code dealing with those has little choice since our select() doesn't 
return the time elapsed.  (and even if it did, it's unclear whether it 
should write back when returning an error on EINTR - the rpc timeout code 
needs to know).

What do you suggest?  Copy the arithmatic and manually inline it (yuck) 
within libc/rpc?  Move the #defines to each of the three libc/rpc files 
that use it?  Create a new private header, eg: <rpc/time.h>?  Something 
else?

> Bruce

Cheers,
-Peter