"M. Warner Losh" wrote on 2006-01-19 19:20 UTC: > Effectively, you'd have to have two time scales in the kernel. UTC > and UTC-SLS. You make it sound simple, but the hair in doing this may > be quite difficult. There's more book for the kernel to keep, and it > would have to expose the bookkeeping to userland for ntp to work. > What makes this hard is that ntpd may introduce steers into the normal > system time at normal times which it doesn't want to confuse with the > steers in frequency that are used during a UTC-SLS operation.
You correctly point out some of the design considerations that have to go into such code. You describe roughly one of the (several) different ways of implementing all this that I have in mind. In comparison to how complicated the Mills kernel PLL is already today, that does not actually sound like an overwhelming additional complexity. Actually, it sounds quite doable when you think through it a bit. Not trivial, but carefully doable without performance penalty. The important thing is: All this has to be done only *once* for each operating system and *once* for each each NTP client/server used on it, by someone who understands the issue, and then the problem is hopefully solved. We've handled far more complicated things in OS kernels, right? I also fully appreciate that the existing *interface* between kernel-level clock drivers and user-level NTP clients and servers is by far not as well specified as it could be. With all due respect to its author, I do not hope that RFC 1589 will not remain the last word on clock-driver interfaces. A detailed proposal for a new standard on that area should help to smooth the process of getting the above right. I think a serious clock-controlling API this is what some people have been asking for for a long time from POSIX. I believe it is good engineering practice to specify the functionality before the interface and implementation, therefore I would like to discuss aspects of desired functionality (including UTC-SLS) before starting to work on a proposed successor to adjtimex(), ntp_adjtime(), etc. I am not claiming that the spec-writing job is finished, or even half finished yet. I see a replacement for RFC 1589 etc. as the next job on the agenda before UTC-SLS (and lots of other time API ideas floating around here and elsewhere) can start to fly. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
