Currently, the kernel uses struct timeval (time_t + microseconds)  
internally for the large majority.  However, POSIX created struct  
timespec (time_t + nanoseconds) and used it in clock_gettime(3), etc.

I think it's time NetBSD moves to using struct timespec in the kernel.

Those syscalls (gettimeofday, select, etc.) which take a struct  
timespec will convert to/from struct timeval as the syscall level.

At the same time, it would be nice to add pselect(2):

int pselect(int nfds, fd_set *restrict readfds,
         fd_set *restrict writefds, fd_set *restrict =
errorfds,
         const struct timespec *restrict timeout,
         const sigset_t *restrict sigmask);

Note that select(2) in libc should be a wrapper around pselect(2).  At
the same time it might make to a struct timespec aware version of poll.

  I propose, for the lack of prior art:

int pollts(struct pollfd pollfds[], int nfds,
         const struct timespec *restrict timeout,
         const sigset_t *restrict sigmask);

Note that for pselect (and my pollts) I'm using the pselect semantics  
for timeout and sigmask:

Implementations may place limitations on the maximum timeout interval  
supported. All implementations shall support a maximum timeout interval
of at least 31 days. If the timeout argument specifies a timeout  
interval greater than the implementation-defined maximum value, the  
maximum value shall be used as the actual timeout value.  
Implementations may also place limitations on the granularity of  
timeout intervals. If the requested timeout interval requires a finer  
granularity than the implementation supports, the actual timeout  
interval shall be rounded up to the next supported value.

If sigmask is not a null pointer, then the pselect() function shall  
replace the signal mask of the caller by the set of signals pointed to
by sigmask before examining the descriptors, and shall restore the  
signal mask of the calling thread before returning.

Inside the kernel, microtime(9) would be replaced by nanotime(9).

This is mostly a mechanical change.

Comments anyone?
--  
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this  
message.