> * Doing an open() and close() on each call not only introduces more
>   overhead, but it specifically introduces jitter.  This is bad.

Yes, I had this idea. I thought it could be added later anyway if
needed. How do you plan to keep state? A static variable in libc, equal
to -1 if the file has not yet been open, equal to the file descriptor if
it had?

Speaking of optimisation, I thought that we could also implement
gettimeofday() by reading a value mmap'ed from kernel memory through the
clockctl device. Some applications call gettimeofday continuously and
there could be a speed up there.
=20
> * The structure arguments to the ioctl(2)s should be the same as the
>   system calls.  They don't need to be copied.

I also thought about this one. I started using sys_settimeofday_args and
folks, but I ended with a double redirection, since I had to handle a
pointer to sys_settimeofday_args, which in turn contained pointers to
struct timeval and struct timezone. Doing it the way it's done there
removes an indirection. I don't see how you will remove a copy by using
sys_settimeofday_args. It even seems to me that we'll need 2 copies
instead of one, one for copying in the struct timeval, and the second
for the struct timezone. Am I wrong here?

> * The way you handle 64-bit return values looks totally wrong.  If
>   there's a big-endian platform (sparc64 would be the only possible
>   one) that requires the shifting, it's broken.

Are you refering to this piece of code in libc?
        q =3D __syscall((quad_t)SYS_clock_settime, clock_id, tp);
        if (/* LINTED constant */ sizeof (quad_t) =3D=3D sizeof (register_t=
)
||
                 /* LINTED constant */ BYTE_ORDER =3D=3D LITTLE_ENDIAN)
                rv =3D (int)q;
        else
                rv =3D (int)((u_quad_t)q >> 32);
        return rv;

I copied it from mmap's system call stub. I assumed it was okay and I
did not checked it for correctness on all our platforms. Is there an
actual problem here? If there is, how does mmap() happens to work on
sparc64?

> * My intent was that ntpd(8) would use this interface exclusively; not
>   use it for some things and the syscall path for others.  In
>   addition, it could easily be handled by a few one-line #ifdefs in
>   ntpd(8) itself, not by hacking up the system call stubs.  Especially
>   since it requires changes to ntpd(8) anyway.

I don't agree here. You could run other applications that needs to set
time apart from ntpd, and having the ability to run them as non root
remains useful. For instance, you can run a ntpdate without being root
(after all who tells you that the packet that is sent back could not be
malformed enough that it will make a buffer overlow in ntpdate?).=20

Additionnaly, the ntp team might not like the idea to implement a
special ntp_adjtime just for NetBSD. Such a change might not go back to
the main ntp CVS.

--=20
Emmanuel Dreyfus. =20
Vous avez deplac=E9 la souris.=20
Windows NT doit maintenant redemarrer pour valider les modifications.
manu@netbsd.org