In message <20050222145841.GY388@canolog.ninthwonder.com>,
Allen Briggs writes:

>On Sat, Feb 19, 2005 at 01:45:04AM -0800, Matt Thomas wrote:
>> 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.
>
>I agree.  I also like the addition of pselect(2) and your proposal
>for pollts(2).

"Me too". If I had had the time, I'd have done it a couple of years
ago.  (Didn't it come up then?)


I'd add one caveat: can you leave select(2) as a syscall?

We'll need an in-kernel select() for many emauls for legacy reasons,
so in the typical case it's not that big a deal.  And that finesses
the thorny issue about whether select(2) treats the timeout value as
an pure input, or may modify it to return the remaining time.  (I know
what our select(2) manpage says, but don't some emuls require the
modify-timeval behaviour?)



>I wonder if it would also be nice to add a nanosecond-resolution
>version of EVFILT_TIMER (EVFILT_TIMESPEC_TIMER ?) to kqueue(2),
>even though the timer is currently tied to the callout mechanism
>and runs at 'tick' resolution.

Oh, <deleted>.  I keep wanting to add a FreeBSD-4 emulation for
kqueue(2), but the ABI differences already make that hairy.  Would you
propose emulating the existing kqueue() ABI in the kernel, or in libc?
If the former, what'd you say about passing function pointers to parse
the ABI differences, versus replicating the body of the code 2 times
(or 3, for a FreeBSD-4 emulation)?